Insinyur Google mengajarkanmu apa itu Loop Engineering? Lima balok＋memori eksternal, mata pelajaran wajib AI tahun 2026

Loop Engineering adalah sebuah sistem yang akan menjalankan proxy prompt secara otomatis, dibangun dari lima blok utama: Automations, Worktrees, Skills, Plugins/Connectors, Sub-agents, ditambah satu memori eksternal. Artikel ini berasal dari insinyur perangkat lunak Google, Addy Osmani.
（Prakata: Anthropic menambahkan fitur deteksi distilasi pada Claude Fable 5, mampu menahan model sumber terbuka dari China? ）
（Tambahan latar belakang: Anthropic: Model AI Amerika Serikat unggul dari China demi melindungi demokrasi, usul menjadikan serangan distilasi sebagai kejahatan pidana）

Daftar isi artikel

Toggle

• Lima blok utama, plus beberapa catatan
• Automations: Detak jantung dari loop
• Worktrees: Jangan biarkan paralel menjadi kekacauan
• Skills: Kamu akhirnya tidak perlu mengulang menjelaskan proyekmu setiap kali
• Plugins dan connectors: Loop menjangkau alat nyata yang kamu gunakan
• Sub-agents: Memisahkan orang yang membuat dan memeriksa
• Seperti apa bentuk sebuah loop
• Hal-hal yang loop belum lakukan untukmu
• Membangun loop, tapi tetap jadi insinyur

Loop engineering adalah mengganti “proxy prompt yang dibuat sendiri” dengan sistem yang kamu rancang untuk melakukan hal tersebut. Yang dimaksud “loop” di sini bisa dipahami sebagai sebuah tujuan rekursif: kamu mendefinisikan tujuan, AI akan mengulang secara iteratif sampai selesai. Saya percaya ini mungkin adalah cara kita berkolaborasi dengan agen pengkodean di masa depan.

Tapi sebelumnya, ini masih sangat awal, saya sendiri juga meragukannya, dan kamu harus sangat berhati-hati terhadap biaya token. Saya ingin membahas ini secara terpisah: apa itu, dan apa maknanya.

Peter Steinberger baru-baru ini berkata: “Kamu seharusnya tidak lagi prompt agen pengkodeanmu. Kamu harus merancang loop yang memprompt agenmu.” Boris Cherny, kepala Claude Code dari Anthropic, juga mengatakan hal serupa: “Saya tidak lagi prompt Claude. Saya biarkan loop berjalan sendiri memprompt Claude, dan loop yang memutuskan apa yang harus dilakukan.”

Dua tahun terakhir, untuk mendapatkan hasil dari sebuah agen pengkodean, kamu menulis prompt yang baik dan memberi cukup konteks. Kamu mengetik satu bagian, membaca responsnya, lalu mengetik bagian berikutnya. Agen adalah alat, dan kamu memegangnya dari awal sampai akhir, satu putaran ke putaran lainnya. Tahap ini hampir berakhir, setidaknya menurut beberapa orang.

Sekarang, kamu membangun sebuah sistem kecil: sistem ini mencari pekerjaan, menugaskan pekerjaan, memeriksa pekerjaan, mencatat mana yang selesai, lalu memutuskan langkah berikutnya, dan sistem ini yang akan memanggil agen, bukan kamu secara langsung. Saya pernah menulis tentang “agent harness engineering” yang serupa, yaitu membangun lingkungan untuk menjalankan satu agen tunggal, sebuah “pabrik” perangkat lunak.

Loop engineering lebih tinggi satu tingkat dari harness: harness tetap ada, tapi ia akan berjalan otomatis, membuat asisten kecil, dan memberi makan dirinya sendiri.

Yang mengejutkan saya, ini bukan lagi soal alat. Setahun lalu, kamu harus menulis loop dengan banyak bash, memeliharanya sendiri, itu adalah milik pribadimu. Sekarang, komponen-komponen ini sudah built-in ke dalam produk. Daftar Steinberger hampir sepenuhnya cocok dengan aplikasi Codex, dan hampir sepenuhnya cocok dengan Claude Code. Begitu kamu menyadari bahwa bentuknya sebenarnya sama, kamu tidak akan lagi berdebat soal “alat mana yang harus dipakai”, melainkan merancang sebuah loop yang bisa berjalan di alat apa pun.

Lima blok utama, plus beberapa catatan

Sebuah loop membutuhkan lima hal, ditambah satu memori. Saya akan daftar dan kemudian memetakan.

2. Automations: Pemicu berdasarkan jadwal, otomatis melakukan discovery dan triage.
3. Worktrees: Memisahkan pengembangan paralel agar tidak saling bertabrakan.
4. Skills: Mengkodekan pengetahuan proyek yang sebelumnya hanya bisa ditebak oleh agen.
5. Plugins dan connectors: Menghubungkan agen ke alat yang sudah kamu pakai.
6. Sub-agents: Satu untuk ide, satu lagi untuk pemeriksaan.

Lalu ada yang keenam: memori. Sebuah file markdown, atau papan Linear, atau apa saja yang hidup di luar percakapan tunggal dan digunakan untuk mencatat “apa yang sudah dilakukan, langkah berikutnya”. Terlihat bodoh dan tidak praktis, tapi ini adalah trik yang diandalkan oleh setiap agen yang berjalan lama. Dalam artikel tentang long-running agents, saya juga bahas: model akan lupa semua di antara eksekusi, jadi memori harus disimpan di disk, bukan di konteks. Agen lupa, repo tidak lupa.

Kedua produk ini sudah memiliki kelima fitur tersebut.

| Kata kunci | | --- | Peran dalam loop | Codex app | Claude Code | | --- | --- | --- | --- | | Automations | Discovery dan triage otomatis berdasarkan jadwal | Tab Automations: pilih proyek, prompt, frekuensi, lingkungan; hasil masuk ke kotak triage; /goal untuk run-until-done | Tugas terjadwal dan cron, /loop, /goal, hooks, GitHub Actions | | Worktrees | Isolasi pengembangan paralel | Setiap thread punya worktree sendiri | git worktree, --worktree, isolasi di subagent: worktree | | Skills | Mengkodekan pengetahuan proyek | Agent Skills (SKILL.md), dipanggil dengan $name atau secara implisit | Agent Skills (SKILL.md) | | Plugins / connectors | Menghubungkan ke alatmu | Connectors (MCP) plus plugin distribusi | Server MCP plus plugin | | Sub-agents | Ide dan verifikasi | Didefinisikan di .codex/agents/ dengan TOML | Di .claude/agents/: Task subagents, tim agen | | State | Melacak status selesai | Markdown atau melalui connector ke Linear | Markdown (AGENTS.md, dokumen progres) atau melalui MCP ke Linear |

Nama-nama ini berbeda di beberapa tempat, tapi esensinya sama. Saya akan bahas satu per satu, karena jujur, detailnya sangat penting: loop akan stabil atau bocor tergantung pada detail ini.

Automations: Detak jantung dari loop

Automations adalah bagian yang membuat “loop” benar-benar menjadi loop, bukan sekadar “kamu menjalankan sekali”. Di Codex app, kamu buat satu automations di tab, pilih proyek, prompt yang akan dijalankan, frekuensi, dan apakah dijalankan di checkout lokal atau background worktree. Jika ada discovery, hasilnya masuk ke kotak triage; jika tidak, otomatis diarsipkan. Sangat nyaman.

OpenAI sendiri menggunakannya untuk hal-hal rutin tapi penting: distribusi issue harian, ringkasan CI gagal, briefing commit, mencari bug yang masuk minggu lalu. Automation bisa memanggil skill, jadi tugas periodikmu bisa dipelihara: cukup trigger $skill-name, bukan menulis rangkaian perintah panjang yang tidak akan pernah diperbarui.

Claude Code juga menggunakan pendekatan yang sama, tapi jalurnya berbeda: melalui jadwal dan hooks. Kamu bisa pakai /loop agar prompt atau perintah dijalankan berulang dengan interval tertentu, atur cron, pakai hooks di titik tertentu dalam siklus hidup agen untuk menjalankan shell, atau push ke GitHub Actions agar tetap berjalan setelah laptop dimatikan. Konsepnya sama: kamu mendefinisikan tugas otomatis, memberi ritme, dan otomatis hasilnya muncul di depanmu, tanpa perlu kamu buka dan cek manual.

Ada satu lagi kata kunci di sesi ini yang penting dan lebih dekat ke inti artikel: /loop adalah menjalankan ulang sesuai ritme. /goal adalah menjalankan sampai kondisi tertentu terpenuhi, dan setiap putaran akan dinilai oleh model kecil lain apakah sudah selesai, jadi “menulis kode” di sini bukan sekadar “menilai”.

Kalau kamu berikan kondisi seperti “semua pengujian di auth/test lulus, lint bersih”, maka proses akan berhenti. Codex juga punya fitur yang sama, disebut /goal, yang berjalan berulang sampai kondisi berhenti yang bisa diverifikasi terpenuhi, bisa pause, resume, dan reset. Kata kunci yang sama ini digunakan di kedua alat, dan ini adalah pola utama dari artikel ini.

Ini bagian dari “mengungkap pekerjaan”. Sisanya adalah “melakukan pekerjaan tersebut”.

Worktrees: Jangan biarkan paralel menjadi kekacauan

Kalau kamu menjalankan lebih dari satu agen secara bersamaan, file akan mulai saling bertabrakan, dan itu bisa menyebabkan kerusakan. Dua agen menulis file yang sama, sama seperti dua insinyur melakukan commit di baris kode yang sama tanpa koordinasi sebelumnya. git worktree mengatasi ini: ia menyediakan direktori kerja terpisah, cabang sendiri, dan berbagi riwayat repo yang sama, sehingga pengeditan oleh satu agen secara fisik tidak akan bertabrakan dengan yang lain.

Codex mendukung worktree secara built-in, jadi beberapa thread bisa bekerja di repo yang sama tanpa saling mengganggu. Claude Code menggunakan git worktree, flag --worktree (agar satu sesi punya checkout sendiri), dan pengaturan isolation: worktree di subagent (setiap asisten mendapatkan checkout baru dan bersih setelah selesai) untuk memberi isolasi yang sama. Dalam artikel tentang orchestration tax, saya bahas dari sudut pandang manusia: worktree menghilangkan benturan mekanis, tapi kamu sendiri yang menentukan kapasitas review dan berapa banyak yang bisa dijalankan secara paralel, bukan alatnya.

Skills: Kamu akhirnya tidak perlu mengulang menjelaskan proyekmu setiap kali

Skill adalah cara agar kamu tidak perlu mengulang menjelaskan konteks proyek yang sama di setiap sesi. Kedua alat menggunakan format yang sama: satu folder berisi SKILL.md, berisi instruksi dan metadata, plus skrip, referensi, aset opsional. Di Codex, skill dipanggil dengan $ atau /skills, atau otomatis dijalankan saat tugas sesuai deskripsi skill. Ini mengapa deskripsi yang tepat dan tidak menarik lebih efektif daripada deskripsi yang menarik tapi tidak spesifik. Claude Code juga memakai pola yang sama, seperti yang saya bahas di artikel tentang agent skills.

Skill juga tempat di mana “niat” tidak perlu dibayar lagi setiap kali. Dalam artikel tentang “debt niat”, saya bahas: agen setiap sesi baru adalah inisialisasi ulang, dan akan mengisi kekosongan niat dengan tebakan percaya diri. Skill menulis niat tersebut di luar — dalam konvensi, langkah build, “kita tidak lakukan itu karena insiden sebelumnya” — tulis sekali, dan agen akan membacanya setiap kali berjalan. Loop tanpa skill akan mengulang dari nol setiap putaran, mengulang seluruh proyekmu. Loop dengan skill akan secara bertahap menumpuk manfaatnya.

Satu hal yang perlu dipahami: skill adalah format penulisan, plugin adalah cara distribusinya. Kalau kamu ingin berbagi skill antar repo, atau mengemas beberapa skill menjadi satu paket, kamu buat plugin. Codex dan Claude Code sama-sama memakai pola ini.

Plugins dan connectors: Loop menjangkau alat nyata yang kamu gunakan

Loop yang hanya melihat filesystem adalah loop kecil. Connectors, yang dibangun di atas MCP, memungkinkan agen membaca issue tracker, mengakses database, memanggil API staging, mengirim pesan Slack. Baik Codex maupun Claude Code sama-sama mendukung MCP, jadi connector yang kamu buat untuk satu alat biasanya bisa langsung dipakai di alat lain. Plugins mengemas connectors dan skills menjadi satu paket, sehingga rekanmu cukup menginstal satu set konfigurasi lengkap, bukan mengingat-ingat lagi.

Ini adalah perbedaan antara “agen memberi tahu ‘ini adalah perubahan’” dan “loop membuka PR sendiri, menghubungkan tiket Linear, mengirim status CI yang hijau ke channel”. Connectors adalah alasan loop bisa melakukan tindakan nyata di lingkungan nyata, bukan sekadar memberi tahu apa yang bisa dilakukan.

Sub-agents: Memisahkan orang yang membuat dan memeriksa

Struktur paling berguna dalam loop adalah memisahkan “yang menulis” dan “yang memeriksa”. Model penulis kode terlalu murah hati memberi penilaian sendiri. Menggunakan agen kedua yang berbeda, yang memiliki instruksi berbeda dan kadang model berbeda, akan menangkap hal-hal yang agen pertama mungkin terjebak percaya diri.

Codex hanya memanggil subagent saat diminta, menjalankan secara paralel, lalu menggabungkan hasilnya menjadi satu jawaban. Kamu definisikan agen di .codex/agents/ dengan TOML, setiap agen punya nama, deskripsi, instruksi, model dan effort reasoning opsional — pengawas keamanan bisa memakai model kuat dengan anggaran reasoning tinggi, peneliti bisa memakai yang cepat dan read-only. Claude Code juga memakai subagent dan tim agen di .claude/agents/: untuk mengirim pekerjaan antar agen. Dua pendekatan umum: satu eksplorasi, satu implementasi, satu verifikasi terhadap spesifikasi.

Saya sudah pernah usulkan dua pola: satu disebut code agent orchestra, satu lagi adversarial code review. Dalam loop, ini sangat penting karena loop berjalan tanpa pengawasan langsung — verifier yang dipercaya adalah satu-satunya yang bisa memastikan “sudah selesai”. Subagent memang akan menghabiskan token lebih banyak, karena harus menjalankan model dan alat sendiri. Jadi, alokasikan di bagian yang memang layak mendapatkan pendapat kedua. /goal di Claude Code secara dasar adalah hal yang sama: dari model baru yang berbeda, diputuskan apakah loop selesai, bukan dari model yang menulis kode — “pelaku vs pemeriksa” diterapkan pada kondisi berhenti.

Kalau kamu berikan kondisi seperti “semua pengujian auth/test lulus, lint bersih”, maka proses berhenti. Codex juga punya /goal yang sama, berjalan berulang sampai kondisi berhenti terpenuhi, bisa pause, resume, reset. Kata kunci ini sama di kedua alat, dan ini adalah pola utama dari artikel ini.

Ini bagian dari “mengungkap pekerjaan”. Sisanya adalah “melakukan pekerjaan tersebut”.

Seperti apa bentuk sebuah loop

Menggabungkan semua ini, satu thread akan menjadi semacam dashboard kecil. Bentuk yang sering saya pakai seperti ini.

Sebuah automations berjalan setiap pagi di repo. Prompt-nya memanggil skill triage, membaca CI gagal kemarin, issue terbuka, commit terbaru, lalu menulis hasilnya ke markdown atau papan Linear. Untuk setiap temuan yang layak, thread ini membuka worktree terisolasi, menugaskan sub-agent untuk merancang solusi, lalu menugaskan sub-agent lain untuk meninjau draft tersebut berdasarkan skill dan pengujian yang ada.

Connectors memungkinkan loop membuka PR, memperbarui tiket. Hal-hal yang tidak bisa ditangani loop langsung masuk ke kotak triage. File status adalah tulang punggung seluruh proses, mencatat apa yang sudah dicoba, apa yang sedang berlangsung, dan apa yang masih terbuka — sehingga putaran pagi berikutnya bisa melanjutkan dari titik terakhir.

Melihat kembali apa yang sudah kamu lakukan: kamu hanya merancang satu kali. Tidak ada langkah yang kamu prompt secara langsung. Ini adalah implementasi konkret dari kata Steinberger tersebut. Dan loop yang sama bisa dijalankan di Codex maupun Claude Code, karena komponennya sama.

Hal-hal yang loop belum lakukan untukmu

Loop mengubah bentuk pekerjaan, tapi tidak menghapus peranmu. Ada tiga masalah yang akan menjadi lebih tajam, bukan lebih ringan, seiring berkembangnya loop.

Verifikasi tetap tanggung jawabmu. Loop yang berjalan tanpa pengawasan adalah loop yang tidak akan pernah diawasi kesalahannya. Memisahkan verifier dan maker adalah alasan utama agar “sudah selesai” punya arti; meskipun begitu, “sudah selesai” hanyalah klaim, bukan bukti. Saya selalu ulangi kalimat dari artikel “code review in the age of AI”: pekerjaanmu adalah mengeluarkan kode yang sudah kamu pastikan bisa dijalankan secara manual.

Pemahamanmu tetap bisa memburuk, selama kamu mengizinkan. Semakin cepat loop mengirimkan produk “bukan kode yang kamu tulis sendiri”, semakin besar jurang antara “yang ada” dan “yang benar-benar kamu miliki”. Ini adalah “comprehension debt” (utang pemahaman), dan loop yang lancar akan mempercepatnya — kecuali kamu membaca apa yang dilakukan loop.

Posisi yang nyaman adalah posisi berbahaya. Ketika loop berjalan sendiri, kamu akan tergoda untuk berhenti memberi penilaian dan menerima apa yang dikembalikan. Saya menyebut ini sebagai “cognitive surrender” (penyerahan kognitif). Merancang loop saat kamu masih punya kemampuan menilai adalah obatnya; saat kamu ingin menghindari berpikir, itu justru mempercepat. Sama saja, tindakan yang sama bisa berakibat berbeda.

Membangun loop, tapi tetap jadi insinyur

Saya percaya ini adalah prediksi arah pekerjaan kita di masa depan. Tapi kembali ke poin utama: jika saya tidak meninjau kode secara langsung, atau mengandalkan otomatisasi penuh, kualitas produk akan menurun. Saya sendiri akan terjebak dalam spiral penurunan, semakin dalam.

Artinya, bangunlah loopmu — tapi jangan lupa, prompt agenmu secara langsung tetap efektif. Segalanya soal menemukan keseimbangan.

Loop juga sangat dipengaruhi oleh “manusia”: dua orang yang membangun loop yang sama bisa mendapatkan hasil yang sangat berbeda. Satu orang menggunakannya untuk mempercepat pekerjaan yang sangat dipahami, orang lain menggunakannya untuk menghindari memahami pekerjaan sama sekali. Jika loop tidak bisa membedakan keduanya, kamu tidak akan tahu mana yang benar.

Itulah mengapa desain loop lebih sulit daripada prompt engineering. Fokus Cherny bukan pada menyederhanakan pekerjaan, melainkan memindahkan titik leverage.

Bangunlah loop, tapi lakukan seperti “insinyur yang ingin terus bekerja”, bukan seperti “orang yang hanya ingin menekan tombol start”.