Ketika manusia masih perlu duduk di depan keyboard dan memberikan petunjuk langkah demi langkah kepada agen, kemampuan intinya adalah menulis prompt. Kini, agen sudah dapat menerima satu tujuan dan menjalankannya sendiri, sehingga kemampuan inti baru adalah rekayasa siklus.

Penulis artikel: CyrilXBT

Artikel diterjemahkan, sumber: ME News

Pada Juni 2026, dalam satu minggu, tiga orang masing-masing secara independen mencapai kesimpulan yang sama.

Pengembang OpenClaw, Peter Steinberger, secara terbuka menyatakan bahwa orang-orang seharusnya berhenti menulis prompt langsung untuk agen pemrograman, dan beralih ke merancang sistem siklus yang dapat secara otomatis mengirim perintah ke agen tersebut.

Pada waktu yang hampir bersamaan, Boris Cherny, pemimpin Anthropic Claude Code, juga menyatakan bahwa ia tidak lagi secara langsung memasukkan petunjuk ke Claude. Sekarang, ia menjalankan serangkaian siklus yang secara otomatis memanggil Claude dan menentukan langkah selanjutnya yang harus diambil, sedangkan pekerjaan sebenarnya adalah menulis dan merancang siklus-siklus tersebut.

Beberapa hari kemudian, insinyur Google Addy Osmani merangkum praktik ini secara sistematis dan memberikan nama:

Loop Engineering, teknik siklus.

Mereka tidak menciptakan cara kerja ini dari nol, tetapi memberi nama pada perubahan yang telah terjadi secara diam-diam.

Karena sebelumnya, alat dasar telah melewati titik kritis penting: agen pemrograman mulai mampu menyelesaikan tugas nyata tanpa pengawasan; biaya penjadwalan otomatis cukup rendah, sehingga menjalankan tugas secara berkala berulang-ulang tidak lagi terasa sia-sia; biaya sekali jalannya agen juga turun ke level baru—lebih baik membiarkan agen mencoba lima kali daripada menghabiskan banyak waktu untuk memikirkan satu kali, karena biayanya mungkin justru lebih rendah.

Ini正是这份路线图存在的原因。

Ketika manusia masih perlu duduk di depan keyboard dan memberikan petunjuk langkah demi langkah kepada agen, kemampuan intinya adalah menulis prompt. Kini, agen sudah dapat menerima satu tujuan dan menjalankannya sendiri, sehingga kemampuan inti baru adalah rekayasa siklus.

Berikut adalah jalur lengkap 20 langkah dari operator prompt menuju desainer sistem. Harus diproses secara berurutan, karena dalam jalur ini, urutan antar langkah seringkali lebih penting daripada langkah mana pun secara terpisah.

Rekayasa siklus bukanlah satu keterampilan tunggal yang "dikuasai" atau "tidak dikuasai", melainkan satu tumpukan kemampuan yang saling bertingkat. Setiap tingkat bergantung pada seberapa kuat fondasi di bawahnya.

Misalnya, membangun pemicu penjadwalan otomatis di langkah 14 sebelum menetapkan kondisi stop yang sebenarnya di langkah 10 hanya akan menghasilkan sistem yang secara otomatis membuang dana tanpa pengawasan. Dulu, sistem setidaknya hanya membuang sumber daya saat Anda memantau layar, sekarang ia bisa terus-menerus membakar uang sendiri.

Demikian pula, jika Anda membangun lapisan memori persisten pada langkah 11 sebelum menyelesaikan mekanisme verifikasi yang andal pada langkah 6 dan 7, Anda mungkin akan secara serius menyimpan pengalaman yang dirangkum oleh "penguji" yang terlalu longgar dan terus-menerus melewati hasil yang salah.

Ini tidak hanya tidak membantu sistem berkembang, tetapi juga menyebabkan akumulasi pengalaman salah, mengubah lapisan memori dari “sementara tidak berguna” menjadi “secara aktif berbahaya”.

Oleh karena itu, melewati beberapa langkah bukan hanya berarti tidak mengimplementasikan satu fitur. Masalah yang lebih serius adalah Anda membangun kemampuan canggih yang tampak menarik di atas fondasi yang sama sekali tidak mampu mendukungnya, dan seringkali baru menyadari masalahnya setelah sistem sudah berjalan dalam skala besar dan menimbulkan konsekuensi nyata.

Langkah pertama yang sebenarnya tidak melibatkan teknologi apa pun.

Anda harus mengakui bahwa dalam alur kerja saat ini, faktor yang membatasi efisiensi sering kali bukan lagi kemampuan model, tetapi Anda sendiri masih terjebak dalam siklus tersebut.

Setiap kali Anda duduk di depan komputer menunggu jawaban dari model, membaca hasilnya, lalu memasukkan perintah berikutnya, Anda menjadi titik paling lambat dalam seluruh sistem.

Model dapat menjalankan, memvalidasi, dan mencoba ulang, dan operasi-operasi ini jauh lebih cepat daripada pengawasan manusia secara bertahap terhadap penyelesaian tugasnya.

Langkah ini tidak memiliki petunjuk yang sesuai, ini adalah keputusan kognitif.

Sebelum Anda benar-benar menerima hal ini, semua langkah selanjutnya akan terlihat seperti pekerjaan tambahan yang tidak perlu, bukan makna sebenarnya—menghilangkan hambatan efisiensi terbesar dalam sistem.

Ketika model menghasilkan output yang bermasalah, reaksi paling alami orang biasanya adalah menambahkan satu aturan lagi ke prompt aslinya.

Beberapa bulan kemudian, praktik ini akan menciptakan dinding tinggi yang terdiri dari aturan: padat konten, saling bertentangan, dan terlalu panjang sehingga model tidak dapat memproses semua persyaratan secara bersamaan dalam memori kerja.

Pada akhirnya, model sering kali hanya dapat melakukan pencocokan pola berdasarkan konten yang paling baru muncul atau paling mencolok, dan secara tidak sadar mengabaikan aturan lainnya.

Circular engineering has completely transformed this approach.

Ketika masalah muncul, Anda tidak lagi hanya menambahkan satu permintaan baru ke prompt, tetapi menambahkan komponen baru ke sistem, misalnya:

• Tambahkan langkah verifikasi independen;
• Tambahkan file memori;
• Tambahkan pemicu terjadwal;
• Tambahkan sesi tinjauan terstruktur.

Seiring dengan peningkatan kemampuan sistem luar, prompt seharusnya semakin pendek, bukan semakin panjang.

Terlepas dari bidang tugas spesifiknya, setiap siklus dalam loop dapat diuraikan menjadi lima tindakan dasar:

Identifikasi, serah terima, verifikasi, persistensi, penjadwalan.

Pengenalan

Tentukan tugas yang benar-benar perlu diselesaikan.

Peralihan

Serahkan tugas ke model, agen, atau alat yang bertanggung jawab untuk eksekusi.

Verifikasi

Periksa apakah hasilnya benar berdasarkan standar yang sebenarnya.

Persistence

Catat apa yang terjadi selama sesi ini, apa yang dipelajari, agar pengalaman tidak hilang pada sesi berikutnya.

Penjadwalan

Tentukan kapan proses ini akan dijalankan kembali.

Alur kerja sebagian besar orang saat ini hanya secara jelas mencakup dua tindakan pertama: mengidentifikasi tugas dan menyerahkan tugas, dan biasanya dilakukan secara manual di jendela obrolan.

Tiga tindakan lainnya either tidak ada sama sekali, atau tersembunyi di dalam otak manusia sendiri.

Inti dari siklus rekayasa adalah membuat kelima tindakan ini secara eksplisit dan semaksimal mungkin mengotomatisasikannya.

Sebelum memulai membangun sistem, pilihlah tugas yang sudah Anda lakukan berulang-ulang dan dapat Anda jelaskan dengan jelas standar kualitasnya.

Jangan memilih masalah paling sulit, atau tugas inovatif tanpa preseden sama sekali.

Tugas kandidat pertama harus memenuhi tiga kondisi:

1. Anda perlu menjalankannya berulang-ulang;
2. Ia memiliki standar jelas yang dapat dituliskan;
3. Ia memiliki "status selesai" yang mudah dikenali.

Dengan kata lain, seorang rekan kerja yang melihat hasilnya harus dapat segera menilai apakah tugas ini telah diselesaikan dengan benar.

Batasan ini lebih penting daripada yang tampak di permukaan.

Jika suatu tugas tidak memiliki kriteria penyelesaian yang jelas, maka tidak mungkin membangun tahap verifikasi yang sebenarnya. Dan sebuah siklus tanpa mekanisme verifikasi yang andal bukanlah siklus yang sejati, melainkan hanya tebakan tanpa pengawasan.

Ini adalah langkah yang paling mudah dilewati oleh kebanyakan orang, namun merupakan langkah kunci yang menentukan apakah sistem selanjutnya dapat berjalan dengan normal.

Sebelum menulis instruksi apa pun untuk agen, tuliskan terlebih dahulu dalam bahasa yang jelas dan alami: hasil yang benar seharusnya seperti apa.

Anda membutuhkan standar yang spesifik dan dapat diperiksa, bukan penilaian kualitas yang kabur seperti "terasa bagus" atau "terlihat profesional".

Anda dapat menggunakan template berikut:

Nama tugas: [Nama tugas]

Definisi Selesai (Definition of Done, DoD):

• [Standar spesifik dan dapat diverifikasi 1]
• [Standar spesifik dan dapat diverifikasi 2]
• [Standar spesifik dan dapat diverifikasi 3]

Meskipun output akhir tampak lengkap dan telah disempurnakan dengan hati-hati, tugas ini tidak dapat dianggap selesai jika ada salah satu hal di atas yang hilang.

Jika Anda tidak dapat mengisi template ini untuk tugas yang dipilih saat ini, kembalilah ke Langkah 4 dan pilih kembali tugas yang lebih cocok untuk membangun siklus.

Ini adalah keputusan arsitektur paling penting dalam semua sistem siklik.

Peran yang bertanggung jawab atas pembuatan hasil harus dipisahkan dari peran yang bertanggung jawab atas pemeriksaan hasil.

Alasannya adalah bahwa ketika model segera meninjau outputnya sendiri setelah menghasilkan konten, ia cenderung membela jawaban yang baru saja dibuat, bukan benar-benar meninjau masalahnya dari sudut pandang kritis.

Dalam satu siklus yang masuk akal, setidaknya harus ada dua peran independen:

Pembangun

Pembangun memiliki ruang kreatif tertentu dan bertanggung jawab atas menghasilkan versi pertama.

Penguji

Reviewer menerima output dari builder dan definisi penyelesaian yang ditetapkan pada Langkah 5, lalu menilai apakah hasilnya memenuhi kriteria tersebut.

Secara ideal, reviewer juga seharusnya dapat mengakses bukti independen yang tidak dapat diakses oleh pembangun, misalnya:

• Test suite;
• Original data;
• Data real-time;
• Database resmi;
• Original task brief.

Dengan cara ini, penilaian reviewer dapat didasarkan pada bukti nyata, bukan menghasilkan ulang pendapat subjektif dengan pemikiran yang sama seperti pembuatnya.

Jika reviewer hanya dapat melihat output dari builder, ia paling banyak dapat menilai apakah hasilnya "terlihat koheren".

It cannot determine whether the result is truly correct.

Oleh karena itu, reviewer harus memiliki dasar objektif yang dapat diverifikasi, yaitu Ground Truth. Berdasarkan konteksnya, hal ini dapat dipahami sebagai "fakta acuan", "data sebenarnya", atau "sumber otoritatif".

Untuk tugas yang berbeda, dasar objektifnya juga berbeda.

Tugas pemrograman

Basis objektif adalah suite pengujian, serta hasil output dari kode yang berjalan secara nyata.

Tugas produksi konten

Dasar objektif adalah sumber asli dan ringkasan konten. Pemeriksa harus membandingkan sumber asli dengan naskah yang dihasilkan secara berdampingan.

Tugas penelitian

The objective basis is the original documents, papers, datasets, or authoritative sources explicitly required for the task.

Jika Anda tidak dapat secara jelas menyatakan apa yang harus menjadi dasar pemeriksaan oleh reviewer, maka siklus Anda belum memiliki mekanisme verifikasi yang sebenarnya, terlepas seberapa percaya diri pun bunyi bahasa reviewer tersebut.

Output dari pembangun dan kesimpulan dari reviewer harus menggunakan struktur yang jelas dan terdefinisi, bukan hanya bahasa alami yang mengalir bebas.

Jika tidak, manajer langkah selanjutnya tidak memiliki informasi yang stabil dan andal untuk membuat keputusan dan pengarahan.

Pembangun dapat menggunakan format output berikut:

Output builder:

• Final deliverable;
• Tingkat kepercayaan terhadap hasil;
• Known uncertainty.

Reviewer dapat menggunakan format output berikut:

Kesimpulan tinjauan:

• PASS: berhasil;
• GAGAL：gagal;
• PERLU DIREVISI:
• Masalah spesifik yang ditemukan;
• Standar objektif atau bukti asli yang menjadi dasar pemeriksaan ini.

Sebelum menghubungkan penjadwalan otomatis dan percobaan ulang otomatis, jalankan secara manual sekali proses "Pembuat—Pemeriksa" secara lengkap.

Baca dengan cermat penilaian yang diberikan oleh reviewer, dan tanyakan pada diri sendiri:

• Apakah Anda setuju dengan kesimpulannya?
• Apakah ia pernah melepaskan hasil yang jelas salah?
• Apakah ia salah menolak hasil yang seharusnya memenuhi syarat?

Jika reviewer melewati hasil yang Anda tahu salah, atau menolak hasil yang sebenarnya tidak bermasalah, perbaiki terlebih dahulu dasar objektif atau standar yang telah ditetapkan, baru lanjutkan membangun sistem.

Mengotomatisasi langkah verifikasi yang salah hanya akan membuat sistem menghasilkan hasil yang salah dengan kecepatan yang lebih cepat.

Untuk membuat lima langkah di atas lebih spesifik, kita dapat mengamati tugas umum: mengubah bahan mentah menjadi sebuah artikel lengkap.

Langkah 5: Menyelesaikan definisi

Kriteria penyelesaian tugas ini dapat berupa:

• Setiap fakta dalam draf dapat dilacak kembali ke konten yang jelas dalam sumber aslinya;
• Draf memenuhi semua persyaratan spesifik dalam laporan tersebut, termasuk panjang, nada, dan struktur;
• Inti argumen asli tetap dipertahankan dengan jelas, tanpa diencerkan oleh konten pengisi yang tidak bermakna.

Langkah 6: Pembangun menghasilkan draf

Pembangun menerima bahan mentah dan ringkasan konten, lalu menghasilkan draf awal.

Sementara itu, ia juga perlu secara jelas mencantumkan ketidakpastian yang ada selama proses penulisan, misalnya:

• Apakah angka tertentu benar-benar muncul dalam sumber aslinya;
• Apakah kesimpulan tersebut secara eksplisit dinyatakan dalam teks asli, atau diambil oleh model secara mandiri;
• Apakah suatu fakta tidak memiliki sumber yang memadai.

Langkah 7: Reviewer memeriksa sesuai teks asli

Reviewer menerima draf dan sumber asli secara bersamaan, bukan hanya draf.

It needs to separately evaluate the three criteria defined in the definition and provide a pass or fail conclusion for each criterion individually, rather than compressing all dimensions into one vague composite score.

Menggabungkan tiga standar berbeda menjadi satu penilaian menyeluruh akan menyamarkan dimensi mana yang mengalami masalah. Ini adalah alasan paling umum mengapa banyak siklus yang sebelumnya berjalan baik secara perlahan kehilangan nilai umpan baliknya.

Langkah 8: Penyerahan terstruktur

Kesimpulan reviewer harus berupa objek terstruktur, bukan paragraf berisi bahasa yang penuh dengan cadangan.

It needs to output three clear pass or fail results, and provide specific reasons for each failure.

Langkah 9: Verifikasi manual mekanisme tinjauan

Sebelum sistem berjalan otomatis, lakukan satu kali proses lengkap secara manual untuk membantu Anda mengetahui apakah reviewer terlalu longgar atau terlalu ketat.

Reviewer yang terlalu longgar mungkin karena artikelnya ditulis dengan lancar, sehingga membiarkan data fiktif di dalamnya.

Reviewer yang terlalu ketat mungkin salah menolak artikel yang memenuhi syarat karena preferensi gaya pribadi yang tidak pernah dicantumkan dalam brief.

Kedua masalah ini sangat umum terjadi saat pertama kali memasang.

Dan menemukannya setelah sistem berjalan tanpa pengawasan sebanyak 50 kali jauh lebih mahal daripada memecahkan masalah saat pengujian manual pertama kali.

Manager bertanggung jawab untuk membaca penilaian reviewer dan menentukan langkah selanjutnya.

Kondisi penghentian juga harus ada dalam manajer, dan harus ditulis sebagai logika keras yang jelas, bukan instruksi lunak yang dapat dilewati oleh model melalui penjelasan mandiri.

Misalnya:

Kondisi penghentian:

• Jumlah maksimum perubahan: 3 kali;
• Ketika peninjauan ketiga masih gagal, kirimkan riwayat lengkap untuk ditangani oleh manusia, jangan memulai perubahan keempat;
• Standar kualitas: Setiap item dalam definisi harus menunjukkan PASS;
• Batas anggaran: Jika biaya tugas melebihi X, atau waktu berjalan melebihi Y, tugas harus segera dihentikan terlepas dari status saat ini.

Siklus tanpa kondisi berhenti yang sebenarnya bukanlah sebuah sistem, melainkan sebuah kewajiban yang menunggu untuk mengekspos risiko.

Mengapa instruksi soft seperti "berhenti ketika hasilnya cukup baik" tidak dapat diandalkan?

Karena itu hanya sebuah saran.

Ketika model telah dimodifikasi berulang kali tetapi masih belum lulus, untuk memberikan akhir yang tampak memuaskan pada tugas tersebut, kemungkinan besar ia akan meyakinkan dirinya sendiri bahwa "versi ini sudah cukup mendekati standar", sehingga secara mandiri menurunkan ambang penilaian.

Sebaliknya, jumlah iterasi yang diperiksa secara mekanis oleh kode, atau aturan jelas yang tidak dapat dihindari oleh manajer melalui penalaran, tidak mengalami masalah semacam ini.

Jika satu siklus dimulai dari nol setiap kali dijalankan, ia tidak akan mengingat apa yang dipelajari dari running sebelumnya.

Oleh karena itu, diperlukan penambahan lapisan persistensi sederhana.

Buat file untuk setiap pengalaman baru yang nyata, dan ringkaskan dalam satu kalimat di atas file:

• Apa yang dipelajari;
• What was fixed;
• Mengapa pengalaman ini penting.

Prinsip utama adalah: hanya mencatat pengetahuan baru yang belum disimpan di tempat lain.

Ingatan berulang bukanlah pengetahuan, melainkan kebisingan.

Untuk memastikan mekanisme persistensi berfungsi secara jangka panjang, harus berhati-hati saat menulis.

Orang mudah tergoda untuk mencatat semua detail operasional, tetapi ini hanya akan mengulangi masalah "promt bengkak" yang disebutkan di Langkah 2, hanya saja kali ini yang membengkak adalah folder memori, bukan prompt.

Pengalaman yang benar-benar patut dicatat adalah yang jika dilupakan, memerlukan banyak waktu untuk ditemukan kembali, bukan sekadar catatan operasi biasa yang berjalan sesuai harapan.

Hanya menambahkan mekanisme persistensi pada akhirnya juga akan menimbulkan masalah serupa dengan prompt yang terlalu panjang.

Seiring berjalannya waktu, sistem akan mengakumulasi puluhan file, banyak di antaranya hanya merupakan pernyataan sedikit berbeda dari masalah yang sama.

Oleh karena itu, file memori harus diatur sesuai siklus tetap. Melakukannya seminggu sekali biasanya merupakan frekuensi yang wajar.

Proses pengaturan mencakup:

• Periksa memori yang ada;
• Gabungkan konten yang berulang;
• Mengompresi beberapa pengalaman serupa menjadi satu prinsip yang lebih jelas;
• Hapus konten yang telah terbukti salah atau usang.

Tujuannya bukanlah mengakumulasi semakin banyak dokumen, melainkan memperoleh pengetahuan yang lebih sedikit jumlahnya namun dengan kepadatan informasi lebih tinggi.

Banyak orang akan melewati langkah ini sepenuhnya, karena tidak langsung memberikan kemampuan baru yang terlihat jelas, hanya mencegah masalah di masa depan.

Namun, justru karena tidak adanya umpan balik langsung, hal ini seharusnya secara jelas dimasukkan ke dalam jadwal, bukan ditunggu sampai seseorang menyadari bahwa folder memori sudah sulit dikelola.

Dalam kenyataannya, tugas semacam "nanti akan diatur saat ada waktu" biasanya tidak pernah terjadi, sampai kinerja sistem mulai menurun karena banyak memori yang bertentangan, usang, dan sebagian terkait bersaing untuk ruang konteks.

Saat setiap tugas baru dimulai, biarkan siklus terlebih dahulu memindai ringkasan satu kalimat dari file memori, menentukan pengalaman mana yang benar-benar relevan dengan tugas saat ini, dan hanya memuat konten terkait tersebut.

Sementara itu, sistem juga harus diminta secara jelas: jika tidak ada memori yang tersedia yang relevan dengan tugas saat ini, langsung nyatakan tidak ada pengalaman yang berlaku.

Jangan memaksakan pengalaman masa lalu ke dalam masalah baru yang sama sekali berbeda hanya karena sistem ingatan sudah ada.

Selanjutnya, perlu menentukan kapan siklus ini akan berjalan otomatis tanpa dimulai secara manual.

Cara pemicu mungkin mencakup:

• Tugas terjadwal Cron;
• File change listener;
• Pemicu siklus berbasis kalender;
• Dipicu ketika terjadi perubahan pada peristiwa atau status eksternal.

Langkah ini akan mengubah sistem yang hanya dapat Anda aktifkan secara manual menjadi sistem yang dapat terus berjalan saat Anda tidur.

Ironisnya, ini biasanya merupakan langkah paling mudah untuk diimplementasikan dalam seluruh daftar, namun juga merupakan langkah yang masih ditunda banyak orang, bahkan setelah mereka menyelesaikan komponen lainnya.

Sebelum menggunakan siklus untuk tugas penting apa pun, lakukan pengujian aktif terhadap empat mode kegagalan.

Pengujian satu: Tugas yang tidak dapat diselesaikan

Berikan sistem tugas yang benar-benar tidak dapat diselesaikan, pastikan manajer dapat keluar sesuai kondisi penghentian, bukan loop tak terbatas.

Jika sebuah siklus hanya diuji pada tugas-tugas yang dapat berhasil diselesaikan, maka ia belum pernah membuktikan kemampuannya untuk gagal dengan elegan.

Pengujian dua: Hasil yang tampak masuk akal tetapi sebenarnya salah

Berikan kepada reviewer sebuah output yang Anda ketahui secara jelas mengandung kesalahan kecil.

Hasil ini seharusnya terdengar sangat lancar, tetapi mengandung kesalahan fakta atau logika yang sengaja Anda tanamkan.

Periksa apakah reviewer dapat menemukan masalah, bukan hanya melewatkannya karena konten terdengar masuk akal.

Uji coba tiga: Pembangun dan reviewer berbagi blind spot model

Jika pembangun dan reviewer menggunakan model dasar yang sama, mereka dapat sengaja memasukkan kesalahan khas yang sering dilakukan oleh model tersebut, lalu mengamati apakah reviewer akan melewatkannya.

Jika reviewer dan builder memiliki blind spot yang sama, maka pemisahan peran yang dirancang pada Langkah 6 menjadi tidak bermakna.

Uji empat: Hitung biaya operasional dalam skenario terburuk

Berdasarkan jumlah maksimum modifikasi, gunakan pemanggilan model paling mahal dan output terpanjang dalam batas wajar, hitung berapa biaya yang diperlukan oleh siklus ini dalam skenario terburuk.

Kemudian tanyakan pada diri sendiri dengan jujur:

Apakah Anda akan merasa khawatir jika angka ini muncul di tagihan nyata?

Lakukan empat pengujian ini sebelum memproses tugas penting dalam siklus kepercayaan, untuk mengidentifikasi sebagian besar masalah potensial sejak dini.

Jika tidak, masalah-masalah ini sangat mungkin muncul pertama kali di hadapan pelanggan atau manajer, atau langsung terlihat pada tagihan Anda, bukan dalam sebuah pengujian yang Anda kendalikan secara aktif.

Setelah siklus berjalan stabil, jangan biarkan semua peran menggunakan model favoritmu yang sama.

Peran yang berbeda dalam siklus memiliki persyaratan yang berbeda terhadap kemampuan model.

Pembangun

Pembangun biasanya harus menggunakan model dengan kemampuan terkuat.

Karena ia menangani tugas penalaran kompleks dan generasi konten utama. Jika menggunakan model yang kurang mampu di sini, kualitas hasil versi pertama akan menurun, dan mungkin memerlukan lebih banyak putaran revisi selanjutnya.

Pada akhirnya, biaya yang dikeluarkan untuk memperbaiki draf awal berkualitas rendah mungkin lebih tinggi daripada biaya yang dikeluarkan untuk menggunakan model yang lebih kuat dari awal.

Reviewer

Reviewer bertanggung jawab untuk memeriksa berdasarkan standar yang jelas, biasanya tidak memerlukan kemampuan kreatif yang tinggi.

Dalam kondisi standar yang cukup spesifik, model yang lebih kecil, lebih murah, dan lebih cepat seringkali juga dapat menyelesaikan tugas tinjauan dengan andal.

Sebuah model kecil yang bekerja berdasarkan daftar periksa yang sangat jelas dapat memiliki stabilitas yang mendekati model besar, tetapi dengan biaya dan latensi yang jauh lebih rendah.

Manager

Manajer hanya melakukan routing sesuai aturan yang sudah ditulis, hampir tidak perlu menggunakan model paling mahal.

Tugasnya adalah menjalankan logika yang telah didefinisikan, bukan melakukan penalaran terbuka.

Selain itu, terlepas dari kinerja pembangun dan reviewer, manajer akan dijalankan setidaknya sekali dalam setiap iterasi, sehingga biaya per panggilannya patut menjadi perhatian khusus.

Konfigurasi lapisan yang wajar biasanya:

• Model kuat yang bertanggung jawab untuk membangun;
• Model yang murah dan stabil bertanggung jawab atas tinjauan rutin;
• Model atau program aturan berbiaya rendah bertanggung jawab atas routing dan manajemen.

Penghematan biaya yang signifikan dalam sistem siklus biasanya berasal dari pencocokan peran model ini.

Banyak orang menganggap bahwa mengendalikan biaya berarti mengurangi jumlah siklus atau revisi. Sebenarnya, metode yang lebih efektif adalah menyesuaikan biaya model dengan tingkat kesulitan aktual setiap peran dalam siklus tersebut.

Setelah siklus pertama berhasil, orang mudah langsung mencoba membangun beberapa siklus sekaligus, memproses lima tugas berbeda secara paralel.

Meskipun arsitektur saat ini sudah mampu mendukung ekspansi ini, sebaiknya kendalikan dorongan tersebut.

Anda harus membiarkan siklus pertama berjalan stabil selama cukup lama, hingga Anda benar-benar tidak lagi perlu memeriksa setiap outputnya secara ketat.

Ini bukan berarti sebuah demo yang semua orang tonton dengan serius berhasil secara kebetulan, tetapi berarti setelah berjalan secara nyata, ia tetap dapat terus lulus pemeriksaan acak oleh manusia.

Hanya setelah mencapai status ini, sebaiknya mulai membangun siklus kedua.

Siklus kedua sebaiknya menangani tugas yang jelas berbeda dari siklus pertama.

Hanya dengan cara ini dapat diverifikasi apakah arsitektur dasar memiliki kegenetisan yang sejati, bukan hanya dilakukan penyetelan yang semakin halus untuk tugas yang sama.

Setelah menjalankan beberapa siklus secara bersamaan, Anda perlu membuat tampilan pemantauan terpusat untuk melacak biaya semua siklus dan kejadian pemicu kondisi berhenti, bukan hanya memeriksa setiap siklus secara terpisah.

Secara terpisah, anggaran tugas siklik mungkin sepenuhnya masuk akal.

Namun, jika kesepuluh siklus berjalan masing-masing dalam batas anggaran, total biayanya masih bisa mencapai tingkat yang mengejutkan.

Karena data independen setiap siklus tampak normal, risiko ini sering kali baru terdeteksi saat laporan ringkasan muncul.

Selain tugas yang berhasil diselesaikan, setiap pemicu kondisi penghentian harus dicatat secara khusus.

Jika suatu siklus sering menyentuh batas perubahan maksimum, sementara siklus lain jarang mengalami hal ini, sinyal yang dikirimkan mungkin bukan "tugas ini sangat sulit", melainkan:

• Kriteria penilaian diatur secara tidak wajar;
• Reviewer terlalu ketat, sehingga tidak ada hasil yang dapat lolos;
• Sistem memeriksa dasar objektif yang salah;
• Menyelesaikan definisi itu sendiri bermasalah.

Jika hanya hasil sukses yang dilacak dan setiap peningkatan manual dianggap sebagai kejadian insidental yang saling terpisah, pola ini pada tingkat desain tidak akan terdeteksi.

Tanda paling jelas bahwa perubahan pola pikir telah benar-benar selesai adalah perubahan pada indikator yang Anda perhatikan sehari-hari.

Yang menjadi perhatian operator prompt adalah:

• Berapa banyak prompt efektif yang ditulis hari ini;
• Prompt mana yang paling efektif;
• Bagaimana cara menulis petunjuk dengan lebih canggih.

Desainer sistem peduli pada:

• Berapa banyak siklus yang sedang berjalan saat ini;
• Seberapa andal setiap siklus;
• Berapa banyak waktu yang telah dirilis oleh sistem;
• Pekerjaan apa yang sudah tidak lagi memerlukan pengawasan manusia.

Jika Anda masih mengukur produktivitas Anda berdasarkan berapa banyak prompt yang Anda masukkan, maka perubahan pola pikir yang diminta pada Langkah 1 belum benar-benar tercapai.

Langkah terakhir sudah tidak lagi sepenuhnya tentang sistem Anda sendiri.

Ini digunakan untuk memverifikasi apakah Anda benar-benar memahami metode ini.

Kamu perlu mencoba menjelaskan lima tindakan dasar kepada orang lain tanpa mengandalkan istilah yang rumit:

Identifikasi, serah terima, verifikasi, persistensi, penjadwalan.

Jika Anda dapat membimbing orang lain untuk membangun siklus pertama mereka hanya dengan lima tindakan ini dan langkah-langkah sebelumnya, berarti Anda telah menyelesaikan transformasi yang dijelaskan dalam peta jalan ini.

Kamu bukan lagi orang yang berada di dalam loop, terus-menerus memasukkan perintah berikutnya.

Anda menjadi orang yang berdiri di luar siklus, merancang sistem dan mengamatinya berjalan sendiri.

Setelah melewati langkah-langkah, empat biaya akan terakumulasi secara diam-diam

Di akhir artikel, diperlukan peringatan.

Melewati langkah-langkah dalam peta jalan ini biasanya tidak langsung menyebabkan sistem gagal.

Kegagalannya biasanya diam, bahkan sulit terdeteksi selama periode waktu yang lama, hingga masalah telah terakumulasi hingga tingkat yang cukup serius.

Ketika Anda melewati langkah ke-6 dan ke-7, tanpa membangun reviewer yang benar-benar independen dan tanpa menyediakan dasar objektif yang dapat diandalkan, verifikasi utang akan mulai menumpuk.

Siklus tampaknya masih berfungsi normal, karena hasil yang dihasilkan "terlihat cukup baik".

Hingga suatu kesalahan terakumulasi selama puluhan kali eksekusi dan akhirnya ditemukan oleh seseorang, baru Anda menyadari bahwa sistem sejak awal tidak pernah benar-benar memeriksa apakah hasilnya benar.

Ketika Anda melewati langkah ke-20, degradasi pemahaman dapat terjadi.

Anda masih menjalankan siklus yang pernah Anda bangun, tetapi sudah tidak dapat menjelaskan dengan jelas mengapa setiap komponen ada, maupun melakukan debugging secara efektif saat terjadi gangguan sistem.

Alasannya adalah karena Anda belum benar-benar menginternalisasi logika di balik arsitektur ini.

Kognitif menyerah terjadi jika langkah pertama tidak pernah benar-benar selesai.

Meskipun sistem verifikasi telah membuktikan keandalannya melalui operasi jangka panjang, Anda tetap akan secara manual memeriksa ulang setiap output karena kebiasaan.

Perilaku ini tampak hati-hati, tetapi sebenarnya menghilangkan seluruh makna dari membangun sistem.

Jika melewati langkah ke-10 dan tidak menetapkan kondisi berhenti yang benar untuk loop, maka konsumsi Token dan biaya pemanggilan dapat menjadi tidak terkendali.

Anda sering tidak menyadari masalah saat sistem mulai kehilangan kendali, melainkan baru menyadarinya ketika tagihan akhir muncul, baru tahu bahwa siklus telah melakukan banyak panggilan tidak efektif.

Semua biaya di atas dapat dihindari.

Cara menghindarinya selalu sama: disiplin:

Bangun secara berurutan, jangan lewati langkah-langkah yang tampaknya kurang menarik.

Yang sering kali benar-benar berperan adalah bagian-bagian paling membosankan:

• Clear completion definition;
• Kondisi berhenti yang andal;
• Bukti objektif yang dapat diverifikasi;
• Independent review mechanism.

Sebaliknya, bagian-bagian yang terdengar lebih menarik—petunjuk yang cerdas, diagram arsitektur sistem yang kompleks—jauh lebih tidak penting daripada yang dibayangkan orang.

Yang benar-benar menentukan kualitas sistem adalah apakah sistem yang Anda bangun tahu:

• Kapan diri sendiri benar;
• Kapan diri sendiri salah;
• Kapan harus berhenti.

It is the entire difference between a prompt operator and a system designer.

Perbedaannya bukan pada siapa yang lebih cerdas, atau siapa yang bisa menulis prompt yang lebih mewah.

Perbedaan sejati adalah apakah Anda memiliki disiplin yang cukup untuk secara serius membangun bagian-bagian yang membosankan dan mudah dilewati, namun benar-benar menentukan keandalan sistem.