TL;DR
· Pada Juni 2026, banyak praktisi pemrograman AI hampir secara bersamaan mengusulkan Loop Engineering, Stripe telah menggunakan Minions untuk menggabungkan lebih dari 1300 PR yang dihasilkan AI setiap minggu.
· Metode ini tidak lagi bergantung pada petunjuk berurutan dari manusia, melainkan sistem secara otomatis menemukan tugas, menyerahkannya, memverifikasi, menyimpan status, dan melanjutkan ke putaran berikutnya.
· Keandalan masih bergantung pada penilai independen, gerbang keras (hard gate), dan tinjauan manual; utang verifikasi dan penurunan pemahaman dapat memperbesar risiko secara terbalik.

Baru-baru ini, seorang insinyur dari Anthropic merilis dokumen 11 halaman tentang "Loop Engineering untuk Sistem Agen", menempatkan Loop Engineering setelah Prompt Engineering, Context Engineering, dan Harness Engineering, sebagai metode kunci AI Programming memasuki tahap berikutnya.

Dokumen ini menarik perhatian karena tepat menyentuh titik balik diskusi AI Programming pada Juni 2026. Addy Osmani, Boris Cherny, dan Peter Steinberger hampir di minggu yang sama menyebut tahap baru AI Programming sebagai Loop Engineering, sementara pipeline Minions Stripe telah menggunakan pendekatan serupa untuk menggabungkan lebih dari 1300 Pull Request yang dihasilkan AI setiap minggu.

Angka ini penting bukan karena AI menulis lebih banyak baris kode, melainkan karena pusat pengembangan perangkat lunak sedang bergeser dari "manusia memberi tahu model apa yang harus ditulis" ke "manusia merancang sistem yang dapat mengantri sendiri, mengambil tugas, menulis kode, memeriksa hasil, menyimpan status, dan terus berjalan".

Selama setahun terakhir, narasi alat pemrograman AI sebagian besar berkisar pada kemampuan model: pelengkapan kode lebih akurat, jendela konteks lebih panjang, agen dapat menyelesaikan tugas yang lebih kompleks dalam satu kali. Namun Loop Engineering membahas hal lain: ketika menghasilkan kode sendiri semakin murah, yang benar-benar perlu dirancang oleh insinyur adalah sebuah siklus yang dapat berjalan secara berkelanjutan. Mesin dapat terus menghasilkan kandidat solusi, manusia harus memutuskan hasil mana yang dapat dipercaya, mana yang harus dihentikan, dan biaya jangka panjang mana yang sedang disembunyikan.

Baru-baru ini, seorang insinyur dari Anthropic merilis dokumen 11 halaman tentang "Loop Engineering untuk Sistem Agen", menempatkan Loop Engineering setelah Prompt Engineering, Context Engineering, dan Harness Engineering, sebagai metode kunci AI Programming memasuki tahap berikutnya. Artikel ini justru menggunakan dokumen tersebut sebagai titik masuk, menggabungkan diskusi publik dari Boris Cherny, Addy Osmani, dan lainnya, serta kasus Stripe Minions yang menggabungkan lebih dari 1300 PR yang dihasilkan AI setiap minggu, untuk menjelaskan apa sebenarnya Loop Engineering, mengapa tiba-tiba dibahas di seluruh jaringan, dan yang benar-benar diubah bukanlah penulisan kode, melainkan verifikasi, penjadwalan, dan penilaian dalam pengembangan perangkat lunak.

AI Programming dari "Prompt Sekali" menuju "Siklus Berkelanjutan"

Loop Engineering ditempatkan setelah Prompt Engineering, Context Engineering, dan Harness Engineering, sebagai lapisan keempat dari tumpukan teknik AI.

Prompt Engineering mengatasi "bagaimana bertanya"; Context Engineering mengatasi "apa yang diperlihatkan ke model"; Harness Engineering mengatasi "bagaimana menghubungkan satu kali eksekusi model ke alat, pengujian, dan alur kerja". Loop Engineering melangkah lebih jauh: sistem tidak hanya menjalankan satu tugas, tetapi dapat memulai ulang pada waktu tetap atau kondisi pemicu, menggunakan hasil sebelumnya sebagai input putaran berikutnya.

Satu siklus lengkap biasanya terdiri dari lima langkah.

Langkah pertama adalah menemukan pekerjaan, misalnya memindai CI gagal, Issue terbuka, komit kode, atau tugas yang tertunda; langkah kedua adalah serah terima tugas, merapikan tugas menjadi konteks yang bisa diproses model; langkah ketiga adalah verifikasi independen, memeriksa apakah kode yang dihasilkan model benar-benar berjalan, lulus tes, dan tidak memperkenalkan efek samping; langkah keempat adalah persistensi hasil, menulis status, penilaian, dan hal yang belum selesai ke file atau sistem; langkah kelima adalah penjadwalan siklus, membiarkan putaran berikutnya berjalan pada waktu yang tepat.

Yang paling krusial di sini bukanlah "generasi", melainkan "verifikasi". Jika sebuah siklus hanya terus-menerus menyuruh model menulis kode, lalu model yang sama memuji hasilnya sendiri, ia dengan mudah menjadi "siklus anggukan": setiap putaran tampak maju, tetapi sebenarnya hanya membungkus kesalahan dengan lebih lengkap.

Siklus triase pagi Osmani sendiri adalah contoh versi personal: sistem setiap hari secara otomatis membaca tes CI yang gagal dari hari sebelumnya, Issue terbuka, dan komit terbaru, menghasilkan file status, dan menempatkan hal yang tidak bisa ditangani ke kotak masuk manual. Nilainya bukan untuk menggantikan insinyur dalam membuat semua keputusan, melainkan menyelesaikan penyaringan awal sebelum insinyur bangun, meninggalkan perhatian untuk bagian yang benar-benar perlu dinilai.

1300 PR Stripe: Keandalan Berasal dari Batasan, Bukan Model

Pipeline Minions Stripe adalah contoh perusahaan paling berdampak dalam diskusi ini: menggabungkan lebih dari 1300 Pull Request yang dihasilkan AI setiap minggu, dan kode itu sendiri tidak ditulis baris per baris oleh manusia.

Namun ini tidak berarti Stripe menyerahkan sistem produksi ke satu model besar untuk bermain bebas. Sebaliknya, kunci Minions terletak pada proses yang sangat terkontrol: orkestrator deterministik pertama-tama merakit konteks, mengekstrak informasi tugas dari Jira, pencarian kode, dan alat internal; LLM bertanggung jawab menghasilkan kode; kemudian melalui linter yang dikodekan keras, gate komit, dan tinjauan manual akhir untuk menentukan apakah bisa digabungkan.

Dengan kata lain, keandalan bukan berasal dari "model yang tiba-tiba cukup pintar", melainkan dari serangkaian batasan. Model bertanggung jawab mengusulkan perubahan kandidat, sistem bertanggung jawab membatasi apa yang bisa disentuh, pemeriksaan apa yang harus dilalui, dan manusia bertanggung jawab atas penilaian akhir apakah akan masuk ke cabang utama.

Ini juga perbedaan antara Loop Engineering dan skrip pemrograman AI biasa. Skrip biasa sering berfokus pada "membuat model menyelesaikan tugas"; sistem siklus harus mempertimbangkan dari mana tugas berasal, bagaimana menangani kegagalan, bagaimana mempertahankan status, bagaimana mengontrol anggaran, dan siapa yang mencegah kesalahan masuk ke lingkungan produksi.

Tanpa batasan ini, 1300 PR per minggu bukanlah lompatan efisiensi, melainkan bisa menjadi mesin pembuat utang teknis.

Generator dan Evaluator Harus Dipisahkan

Satu desain inti dari Loop Engineering adalah memisahkan generator dan evaluator.

Generator bertanggung jawab menulis kode, mengubah file, dan mengirimkan hasil kandidat. Evaluator bertanggung jawab mencari kesalahan, dan sebaiknya secara default menganggap kode bermasalah. Keduanya tidak bisa dilakukan oleh "agen optimis" yang sama, karena model saat menilai diri sendiri cenderung menyetujui outputnya sendiri, terutama ketika deskripsi tugas ambigu, cakupan pengujian tidak memadai, atau konteks tidak lengkap.

Evaluator independen bisa lebih sederhana, lebih curiga, dan lebih mudah disetel. Ia tidak perlu memecahkan masalah secara kreatif, hanya perlu memverifikasi apakah halaman bisa dibuka, apakah tes lulus, apakah kondisi batas dilanggar, dan apakah kode sesuai aturan yang ditetapkan. Beberapa praktik membuat evaluator benar-benar mengklik halaman melalui alat otomatisasi browser, bukan hanya membaca kode lalu memberikan penilaian.

Ini menjelaskan mengapa "verifikasi" adalah langkah paling sulit dalam siklus lima langkah. Generasi kode sudah semakin murah, tetapi membuktikan bahwa sepotong kode benar-benar tepat masih mahal. Terutama di basis kode besar, kesalahan tidak selalu segera terungkap, dan pengujian belum tentu mencakup jalur bisnis nyata. Semakin cepat siklus berjalan, semakin cepat asumsi yang belum diverifikasi terakumulasi.

Biaya Tersembunyi Saling Memperkuat

Risiko Loop Engineering bukanlah apakah ia bisa menulis kode yang salah, melainkan bahwa ia bisa membuat tim lebih sulit menyadari bahwa mereka telah kehilangan pemahaman.

Kategori biaya pertama adalah utang verifikasi. Kesalahan yang tidak tercakup oleh pengujian akan terus terakumulasi dalam siklus, hingga meledak secara terkonsentrasi saat penggabungan atau peluncuran. Kategori kedua adalah penurunan pemahaman. Basis kode terus membengkak, tetapi insinyur tidak secara langsung mengalami pilihan desain kunci, peta mental mereka tetap pada versi lama. Kategori ketiga adalah penyerahan kognitif. Manusia mulai secara default menerima output mesin, hanya memberikan persetujuan formal. Kategori keempat adalah ledakan konsumsi token. Pengulangan, sub-agen, konteks panjang, dan verifikasi multi-putaran akan meningkatkan tagihan dengan cepat.

Keempat biaya ini saling memberi makan: pengujian yang tidak memadai menyebabkan utang verifikasi, peningkatan utang verifikasi membuat insinyur enggan memahami secara mendalam, penurunan pemahaman mengubah tinjauan manual menjadi stempel karet, dan tinjauan stempel karet mendorong lebih banyak pengulangan otomatis dan biaya lebih tinggi.

Oleh karena itu, seperangkat komponen siklus yang sama dapat menghasilkan hasil yang sangat berlawanan di tangan insinyur yang berbeda. Mereka yang memiliki penilaian kuat dan batas yang jelas dapat menggunakan siklus untuk memperkuat pemahaman mereka tentang sistem, menjadikan mesin sebagai lapisan eksekusi yang tak kenal lelah; mereka yang penilaiannya lemah atau terlalu bergantung pada otomatisasi, setelah beberapa bulan bisa menjadi "penjaga gerbang" sistem mereka sendiri, hanya menyetujui atau menolak, tetapi tidak bisa menjelaskan mengapa sistem berjalan seperti itu.

Setelah Kode Menjadi Lebih Murah, yang Mahal adalah Penilaian

Loop Engineering mendorong tren jangka panjang ke posisi yang lebih jelas: kode, rencana, PR, dan pemecahan tugas menjadi hampir gratis, tetapi "apa yang benar-benar benar" tidak menjadi lebih murah.

Bagi perusahaan, ini berarti fokus investasi AI Programming mungkin beralih dari membeli model yang lebih kuat ke merancang proses yang lebih stabil: batas tugas, perakitan konteks, evaluasi independen, persistensi status, batas anggaran, titik tinjauan manual, dan cara menghentikan siklus saat terjadi anomali. Kemampuan model masih penting, tetapi hanya bagian dari sistem.

Bagi insinyur, peran juga berubah. Dulu tenaga kerja inti adalah menulis kode, sekarang semakin banyak tenaga kerja berubah menjadi meninjau jawaban kandidat yang dihasilkan mesin: apakah sesuai dengan kebutuhan, apakah merusak arsitektur, apakah hanya terlihat masuk akal, apakah mendorong kompleksitas ke pemelihara di masa depan.

Ini tidak berarti programmer sudah digantikan. Sebaliknya, Loop Engineering lebih seperti amplifier penilaian. Ia bisa membuat seorang insinyur menghasilkan volume perubahan yang biasanya hanya bisa dicapai tim kecil, dan juga bisa memperbesar kebiasaan malas, percaya buta, dan kurang verifikasi menjadi kecelakaan produksi.

Persimpangan sebenarnya terletak pada apakah manusia masih mempertahankan penilaian dan hak veto yang cukup kuat. AI dapat terus mengirimkan PR, tetapi apakah bisa digabungkan, apakah perlu diluncurkan, dan apakah dalam jangka panjang akan merusak sistem, masih bergantung pada manusia.

Klik untuk memahami lowongan kerja di律动BlockBeats

Selamat bergabung dengan komunitas resmi律动 BlockBeats:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Twitter Official Account: https://twitter.com/BlockBeatsAsia