Rekayasa loop sedang naik daun. Telusuri forum teknis mana pun dan Anda akan menemukan suara-suara yang berargumen bahwa kita harus berhenti memperlakukan agen AI seperti chatbot yang perlu dilatih dengan prompt cerdas. Sebaliknya, mereka mengatakan, kita harus merancang loop: siklus otonom yang memungkinkan agen untuk merencanakan, mengeksekusi, memeriksa pekerjaannya sendiri, dan melakukan iterasi saat kita tidur. Tawarannya sangat menggoda. Jika loop dibangun dengan baik, agen akan tetap pada jalurnya tanpa pengawasan manusia yang konstan, mengubah niat mentah menjadi hasil akhir dalam semalam.
Janji itu bekerja dengan indah secara teori. Dalam praktiknya, sebagian besar agen sudah melakukan looping. Mereka menghasilkan kode, memeriksa kesalahan kompiler atau kegagalan pengujian, menambal kode, dan menjalankan rangkaian pengujian lagi. Siklus umpan balik dasar itu bukanlah hal baru. Apa yang dituntut oleh para pendukungnya sekarang adalah sesuatu yang lebih ambisius: sebuah loop luar yang mengatur seluruh tugas, bukan hanya kesalahan sintaksis. Membangun loop luar tersebut adalah bagian yang sulit, karena rekayasa perangkat lunak jarang sekali menjadi sistem tertutup dengan aturan yang tetap.
Masalah Desain Loop
Tujuan produk itu berantakan. Anda jarang memulai dengan definisi 'selesai' yang sempurna. Sering kali, Anda baru menemukan tujuan sebenarnya saat sedang sibuk-sibuknya dalam proses pembangunan. Persyaratan yang terdengar sederhana di papan tulis ternyata memiliki kasus tepi (edge cases) yang mengubah bentuk solusi sepenuhnya. Saat Anda membungkus agen di dalam loop yang kaku, kekakuan tersebut menjadi beban. Loop tersebut terus memukul target yang mungkin salah. Lebih buruk lagi, loop yang fleksibel terkadang menyelesaikan kebuntuan dengan diam-diam mengubah tujuan agar sesuai dengan output apa pun yang berhasil dihasilkannya. Kedua hasil tersebut tidak berguna. Yang satu membuang-buang daya komputasi; yang lainnya mengirimkan sampah dengan penuh percaya diri.
Masalah yang lebih dalam adalah biaya spesifikasi. Jika Anda ingin loop berjalan tanpa pengawasan, Anda harus menulis spesifikasi yang mengantisipasi hampir segalanya. Apa sebenarnya yang harus diubah oleh agen? Perilaku yang ada mana yang sakral dan harus dipertahankan? Dalam kondisi tepat seperti apa agen harus berhenti melakukan iterasi? Risiko mana yang dapat diterima, dan efek samping mana yang harus memicu penghentian segera? Menulis dokumen tersebut bisa memakan waktu lebih lama daripada sekadar duduk bersama agen dan mengarahkannya melalui tugas tersebut secara real-time. Anda membayar pajak di muka yang besar demi otomatisasi yang hanya akan menguntungkan jika verifikasinya jauh lebih murah daripada proses pengerjaannya.
Di Mana Loop Benar-benar Memberikan Nilai
Itu tidak berarti rekayasa loop tidak berguna. Itu berarti ini adalah alat khusus, bukan strategi universal. Loop bersinar ketika biaya verifikasi berlipat ganda dan kriteria keberhasilan tidak ambigu. Ada tiga tempat di mana hal ini cenderung berlaku.
Pekerjaan mekanis rutin. Pikirkan tugas-tugas yang membuat insinyur senior ingin pensiun: memulai aplikasi dalam urutan tertentu, mengklik antarmuka deployment untuk mengonfirmasi setiap tahap, mencari log (grepping logs) untuk string kesalahan yang diketahui setelah rilis, atau memvalidasi bahwa file konfigurasi telah ditulis ke semua node yang tepat. Langkah-langkah ini membosankan bagi manusia tetapi sepele untuk diverifikasi. Sebuah loop dapat mengawasi proses tersebut, memeriksa endpoint kesehatan setelah setiap restart dan melakukan rollback pada tanda-tanda pertama adanya masalah. Manusia tetap menentukan rencana rollout. Loop tersebut hanya mengeksekusinya dengan kesabaran mesin pada jam dua pagi.
Tujuan optimasi yang terukur. Ketika keberhasilan adalah sebuah angka, loop sangatlah efektif. Turunkan latensi p99 di bawah 150 milidetik. Kurangi jejak memori sebesar dua puluh persen. Migrasikan hot path dari Python ke Rust dan pastikan semua unit test yang ada tetap lulus. Loop dapat menghasilkan perubahan, melakukan benchmark, menyimpan varian yang memberikan hasil signifikan, dan membuang sisanya. Karena verifikasi bersifat otomatis dan ruang pencarian sangat luas, biaya akumulasi peninjauan manual akan membuat pekerjaan ini tidak praktis tanpa loop. Targetnya tetap. Jalannya tidak diketahui. Itulah titik idealnya.
Playbook operasional. Respons insiden dan tiket dukungan sering kali mengikuti pola yang sudah dipahami manusia. Kelas kesalahan produksi tertentu selalu memerlukan rotasi kredensial dan pembersihan cache. Kategori permintaan dukungan dapat diselesaikan dengan pengembalian dana (refund) ketika tiga kondisi tertentu terpenuhi. Sebuah loop dapat memantau pemicu tersebut dan menjalankan playbook, melakukan eskalasi hanya ketika polanya rusak. Ia tidak memutuskan apakah playbook tersebut benar; ia hanya menegakkan konsistensi pada skala dan kecepatan yang tidak dapat ditandingi oleh insinyur on-call.
Regulator, Bukan Penentu Referensi
Ada perbedaan krusial yang hilang dari banyak percakapan saat ini. Loop adalah regulator. Mereka menjaga sistem tetap selaras dengan target yang telah ditentukan sebelumnya, layaknya termostat yang menjaga suhu ruangan tetap di tujuh puluh dua derajat. Namun, termostat tidak memilih angka tujuh puluh dua tersebut. Seseorang harus memutuskan terlebih dahulu bahwa itulah suhu yang tepat.
Jika diterapkan pada perangkat lunak, ini berarti sebuah agen di dalam sebuah loop dapat memperbaiki bug, melakukan refactor fungsi, atau menyetel parameter sepanjang hari. Namun, ia tidak dapat memutuskan fitur mana yang benar-benar membantu pelanggan atau apakah sebuah bug layak diperbaiki sebelum rilis berikutnya. Pilihan-pilihan tersebut memerlukan penilaian tentang konteks bisnis, kesulitan pengguna, dan prioritas strategis. Agen mengeksekusi. Manusia memutuskan. Mencampuradukkan keduanya adalah alasan mengapa tim akhirnya memiliki sistem yang dioptimalkan dengan sangat indah namun menyelesaikan masalah yang salah.
Loop engineering itu berguna, tetapi cakupannya sempit. Ini membantu Anda menjalankan mesin dengan disiplin dan kecepatan. Ia tidak memutuskan mesin apa yang harus dibangun, untuk siapa mesin itu, atau seperti apa kesuksesan dalam istilah manusia. Penilaian mengenai fitur mana yang penting, risiko mana yang dapat diterima, dan kapan tujuan itu sendiri perlu diubah, ada pada Anda. Bangunlah loop untuk pekerjaan yang sudah Anda pahami cukup baik untuk diverifikasi secara otomatis. Tetaplah memegang kendali atas segala hal lainnya.
Artikel ini mengambil ide-ide yang awalnya dibahas oleh Isaac Hagoel dalam “Loop Engineering Minus The Hype.”. Untuk diskusi teknik lebih lanjut, bergabunglah dengan komunitas belajar kami di Telegram.