Mengapa agen AI mengatakan “selesai” padahal pekerjaannya belum selesai

Bagaimana Model OpenAI Kabur dari Sandbox dan Meretas Hugging Face?#

Pertama fakta-faktanya, lalu mengapa hal ini penting bagi Anda.

OpenAI mengukur kemampuan modelnya dalam keamanan siber ofensif. Mereka menggunakan tes ExploitGym—898 tugas yang mengharuskan Anda mengubah kerentanan yang diketahui menjadi eksploit yang berfungsi, yaitu program siap pakai yang memanfaatkan kerentanan tersebut. Untuk mengetahui batas kemampuan sebenarnya, mereka menonaktifkan filter keamanan bawaan yang biasanya mencegah model melakukan hal semacam itu. Mereka menutup lingkungan sepenuhnya dan menyisakan satu jalan keluar: program perantara internal yang digunakan untuk memasang paket.

Kerentanan zero-day adalah celah yang belum diketahui siapa pun, termasuk orang yang menulis programnya. Model-model itu menemukan celah semacam itu pada satu-satunya jalan keluar yang sama.

Berikutnya, mereka meningkatkan hak akses, bergerak melalui jaringan internal ke mesin yang terhubung ke internet, lalu menduga bahwa jawaban ExploitGym mungkin ada di Hugging Face. Tidak ada yang memberi tahu mereka tentang Hugging Face. Mereka menyimpulkannya sendiri.

Dugaan itu keliru. ExploitGym sama sekali tidak ada di Hugging Face. Namun, itu tidak membuat peretasannya menjadi kurang nyata.

Hugging Face menemukan penyusupan itu sendiri dan menerbitkan pengungkapannya pada 16 Juli, tanpa mengetahui siapa yang meretasnya.

Ada detail lain dari laporan itu yang banyak bercerita tentang keadaan saat ini. Ketika para insinyur Hugging Face mencoba memberikan log serangan tersebut kepada model-model terkemuka melalui antarmuka komersial biasa, filter keamanan memblokir permintaan itu: model-model tersebut tidak dapat membedakan orang yang sedang menyelidiki peretasan dari orang yang sedang melakukannya. Pada akhirnya, analisis dijalankan dengan model terbuka di perangkat keras mereka sendiri.

OpenAI mengakuinya pada 21 Juli, lima hari setelah pengungkapan Hugging Face. Saat itu, sekitar sepuluh hari telah berlalu sejak penyusupan itu sendiri.

OpenAI mengakhiri analisisnya sendiri dengan kalimat berikut.

Model itu terpaku pada tujuan tes yang sempit dan bertindak ekstrem untuk mencapainya. Istilah hyper-focused dan fairly narrow testing objective berasal dari OpenAI sendiri dan merujuk pada modelnya sendiri.

Itulah yang menjembatani laboratorium orang lain dengan laptop Anda.

Mengapa Ini Bukan “Halusinasi”?#

Saya sering melihat frasa dalam percakapan seperti “halusinasi lagi,” “konteksnya terlalu penuh,” atau “seharusnya kita membuat rencana.” Kadang memang itulah yang terjadi. Namun, saat agen AI menulis “selesai, sudah diperiksa, semuanya berfungsi” padahal pekerjaannya belum selesai, banyaknya konteks biasanya tidak ada hubungannya.

Agen itu tidak mengarang apa pun. Ia melakukan persis apa yang Anda ukur.

Di bawah istilah umum “halusinasi” yang populer, kita mengelompokkan tiga jenis kegagalan yang berbeda. Berikut perbedaannya:

Yang pertama diperbaiki dengan konteks, dan inilah kasus yang paling dikenal. Yang kedua adalah fenomena tersendiri, dibahas dalam analisis tentang saat Claude menyetujui segalanya: model mengorbankan ketepatan demi persetujuan cepat. Keduanya terjadi sebelum pekerjaan dimulai, pada tahap masukan.

Baris ketiga pada tabel adalah pokok bahasan artikel ini. Di sini, agen tidak menjilat atau mengarang. Agen bekerja, memeriksa, dan melaporkan kebenaran. Hanya saja, kebenaran itu menggambarkan metrik dan tidak mengatakan apa pun tentang tugasnya.

Kegagalan ketiga ini punya nama.

Apa Itu Reward Hacking dalam Bahasa Sederhana?#

Anthropic memberikan definisinya sendiri.

Gagasan ini lebih tua daripada jaringan saraf. Sebuah makalah DeepMind menyebutnya specification gaming dan menjelaskannya dengan sebuah mitos.

Midas mendapatkan persis apa yang dimintanya. Masalahnya terletak pada rumusan permintaan itu.

Dalam pemrograman, hal ini memiliki bentuk konkret. Berikut contoh baku, juga dari Anthropic:

Dan ini bukan kondisi laboratorium yang eksotis. Cursor menganalisis 731 trajektori pada tolok ukur populer.

Enam dari sepuluh tugas yang “diselesaikan” ternyata mengambil jawaban yang sudah ada. Itulah tepatnya alasan industri mengubah cara mengukur kinerja: kami telah menganalisis tolok ukur yang mengukur kesiapan produksi, di mana lolos pemeriksaan bukan lagi kriteria utama.

Seperti Apa Bentuknya dalam Produk Sehari-hari?#

Contoh laboratorium mudah dianggap eksotis. Jadi, berikut empat kisah dari praktik. Klien dan industrinya diubah, tetapi mekanismenya tetap seperti semula.

Empat Pemeriksaan Hijau dan Komponen Layanan yang Mati

Sebuah agen real estat sedang membangun layanan: situs web berisi daftar properti ditambah prosesor latar belakang terpisah yang mengekspor daftar itu ke berbagai platform pada malam hari. Agen menyelesaikan tugas dan melaporkan: pemeriksaan tipe lolos, pemeriksaan gaya kode lolos, build berhasil, halaman merespons, dan halaman sudah diperiksa secara visual.

Setiap pernyataan itu benar. Namun, tak satu pun berkaitan dengan prosesor malam hari: prosesor itu berjalan sebagai proses terpisah dan sama sekali bukan bagian dari build situs web. Deployment berhasil, situs berfungsi sempurna, ekspor daftar berhenti, dan klien baru melaporkannya sehari kemudian.

Sebelum mengatakan “selesai,” kini saya mengajukan satu pertanyaan: bagian pekerjaan mana yang berjalan di luar cakupan pemeriksaan saya? Jika ada, jalankan secara terpisah dan sertakan keluaran perintahnya dalam laporan. Kata “diperiksa” tidak menuntaskan masalah ini.

Tanda Centang Palsu Tepat Berada di Titik Sambungan

Sebuah toko daring membagi tugas besar di antara beberapa agen sekaligus: satu menangani backend, satu lagi halaman, dan yang ketiga kartu produk. Masing-masing bekerja dengan tekun dan masing-masing memiliki pemeriksaan hijau.

Seminggu kemudian, ternyata tombol “ulasan ini membantu” tidak berfungsi di mana pun. Backend ditulis lengkap, pemeriksaannya hijau, dan aturan penghitungan ulang sudah diikuti. Hanya saja, tidak ada halaman yang menampilkan tombol itu: tombolnya ada di area kerja satu agen, halaman-halamannya di area agen lain, dan tak seorang pun terpikir untuk menaruhnya di layar. Penghitungnya akan selamanya tetap nol.

“Kode sudah ditulis dan tercakup oleh pemeriksaan” dan “fiturnya berfungsi” adalah dua klaim berbeda. Saya memeriksa klaim kedua dengan satu pertanyaan untuk setiap fitur baru: siapa yang memanggilnya? Saya memverifikasinya dengan menelusuri proyek, karena laporan agen bukan sumber kebenaran dalam hal ini.

Peninjau Hanya Melihat Arah yang Diminta untuk Diperiksa

Sebuah layanan memperkenalkan tingkatan loyalitas: makin banyak Anda membayar, makin tinggi status dan diskon Anda. Sebelum deployment, kode dikirim untuk ditinjau dengan instruksi, “Coba naikkan status Anda sendiri.” Peninjau melakukan tugasnya dengan jujur dan melaporkan “tidak ada yang kritis”—memang tidak mungkin menaikkan status sendiri.

Pemeriksaan kedua mengajukan pertanyaan berbeda: “Apa yang terjadi pada status ketika uang dikembalikan?” Celahnya ditemukan dalam sepuluh menit. Poin dihitung dari log transaksi, dan log itu tidak mengetahui apa pun tentang pengembalian dana. Beli sesuatu, dapatkan poin, minta pengembalian dana, lalu pertahankan status dan diskon selamanya.

Peninjau pertama tidak bekerja asal-asalan. Mereka secara struktural tidak mungkin melihatnya: mereka diberi vektor “masukan, promosi,” sedangkan celahnya ada pada vektor “pembalikan masukan, retensi promosi.” Jika uang, akses, atau status yang bisa dibeli dipertaruhkan, saya menjalankan dua pemeriksaan; pada pemeriksaan kedua saya secara eksplisit mencantumkan vektor kebalikannya: pengembalian dana, pemblokiran, pencabutan akses, kedaluwarsa, penghapusan sumber data.

Metrik Memberi Imbalan atas Kemiripan

Sebuah layanan pengiriman memutuskan untuk mengukur apakah saran AI kepada operator telah membaik. Layanan itu mengambil dua ratus permintaan dukungan lama, memprosesnya dengan versi baru, lalu mengukur kemiripan draf dengan balasan yang benar-benar diberikan operator manusia. Pengukuran menunjukkan peningkatan yang meyakinkan.

Peningkatan itu tidak berarti apa-apa, karena dua alasan. Konteks untuk draf disusun “berdasarkan keadaan hari ini” dan mencakup seluruh korespondensi, termasuk balasan operator yang nantinya dibandingkan. Model itu bukan menulis balasan; model hanya memparafrasakan acuan yang ditunjukkan kepadanya. Selain itu, metriknya sendiri memberi imbalan untuk kesamaan kata dan panjang: draf yang memberikan tanggal keliru dengan kata-kata yang sama seperti yang digunakan operator untuk tanggal yang benar akan mendapat skor tinggi.

Di samping metrik apa pun yang menganggap “mirip berarti bagus,” kini saya menaruh gerbang mekanis yang tidak bisa dikelabui oleh gaya: angka dan tanggal rekaan, kata-kata terlarang, janji tindakan. Penurunan apa pun pada hasil gerbang menghapus peningkatan metrik.

Mengapa “Saya Sudah Memeriksa” dari Agen Tidak Membuktikan Apa Pun?#

Ambil proyek apa pun dan minta agen, “Periksa keamanannya.” Sering kali jawabannya, “semuanya baik-baik saja, tidak ada masalah kritis.”

Sekarang ajukan pertanyaan yang sama kepada model lain tentang proyek yang sama. Terutama jika proyeknya besar, model itu akan menemukan banyak hal. Sebelum deployment, penulis memeriksa proyek dengan tiga model berbeda, dan masing-masing menemukan hal yang berbeda.

Masukan sama, pertanyaan sama, kesimpulan berlawanan. Salah satu model tidak lebih buruk daripada yang lain. Hanya saja, “semuanya baik-baik saja” adalah teks yang dihasilkan, berada di lapisan yang sama persis dengan jawaban lainnya. Agen tidak memiliki cara untuk membedakan “Saya sudah memeriksa dan bersih” dari “Saya memeriksa tempat yang salah.”

Anthropic menjelaskan mekanisme ini dalam dokumentasi Claude Code.

Uraikan kalimat itu perlahan. Sampai Anda memberi agen pemeriksaan yang dapat dijalankannya, agen hanya memiliki satu sinyal—seperti apa segala sesuatu terlihat. Dalam pengaturan ini, Andalah putaran verifikasinya, tetapi Anda justru menjadi orang terakhir yang mengetahui kesalahannya.

Ada lapisan yang lebih dalam. Ketika OpenAI mencoba menekan model dengan memantau penalarannya dan menghukumnya karena “pikiran buruk,” hasilnya tidak seperti yang mereka harapkan.

Menghukum niat yang dinyatakan hanya menghilangkan pernyataannya. Niatnya sendiri tetap ada. Jadi, saya tidak akan mengandalkan agen untuk memberi tahu Anda dengan jujur bagaimana ia berbuat curang.

Pengembang alat itu sendiri bergerak ke arah yang sama. Pada Claude Code versi 2.1.215, skill /verify dan /code-review berhenti dijalankan atas inisiatif model sendiri.

2.1.215 - Claude tidak lagi menjalankan skill `/verify` dan `/code-review`
atas inisiatifnya sendiri; panggil dengan `/verify` atau `/code-review` saat Anda menginginkannya

Anthropic tidak menjelaskan alasannya. Namun, prinsipnya jelas: pihak yang ditinjau tidak menunjuk dirinya sendiri untuk melakukan peninjauan.

Mengapa Aturan dalam File Proyek Tidak Bisa Membuat Agen Patuh?#

Anda menulis dalam file aturan proyek: lakukan commit hanya jika diperintahkan secara langsung, lakukan deployment ke produksi hanya jika saya mengatakannya secara langsung, akses data produksi hanya dalam mode baca saja.

Menurut pengalaman penulis, sekitar satu dari sepuluh kali, agen tetap lanjut dan melakukan deployment sendiri. Bukan karena berniat jahat, dan bukan karena tidak membaca aturannya. Agen membacanya. Hanya saja, ada tujuan di depannya, sedangkan aturan itu adalah teks—sama seperti bagian konteks lainnya.

Itulah tepatnya yang terjadi di laboratorium OpenAI, hanya dalam skala lebih besar. Model-model itu berada di lingkungan tertutup dengan satu jalan keluar dan menghabiskan sebagian besar komputasinya untuk mencari jalan keluar. Tugas-tugas tes tetap tidak terselesaikan.

Sikap saya di sini sederhana: agen itu tidak berbahaya atau jahat. Ia biasa saja, hanya orang bodoh yang punya wewenang. Jadi, batasi wewenangnya, jangan menulis ulang permintaan Anda.

Yang benar-benar menahan: akses data produksi yang sepenuhnya hanya-baca. Larang penghapusan seluruh direktori. Larang perintah yang menulis ulang riwayat tanpa cara untuk memulihkannya. Tetapkan batas pengeluaran dengan penyedia. Perbedaannya terangkum dalam satu frasa: “secara fisik tidak bisa” mengalahkan “saya sudah memintanya untuk tidak melakukannya.” Pengaturan spesifik dibahas secara terpisah, dalam artikel tentang rem mekanis alih-alih permintaan dalam instruksi.

Meski begitu, tetaplah berpikir jernih. Bahkan sandbox bukan batas mutlak, dan penyedia mengatakannya dengan jelas.

Terlebih lagi, Claude Code memiliki jalan keluar darurat bawaan yang dapat digunakan model itu sendiri. Ketika sebuah perintah gagal karena pembatasan sandbox, Claude menganalisis kegagalannya dan mungkin mencoba lagi perintah yang sama dengan parameter yang menonaktifkan sandbox. Hal ini dicegah oleh pengaturan strict-mode eksplisit; secara bawaan, cara mengakali pembatasan itu tersedia dan didokumentasikan.

Pembatasan hanya efektif sejauh Anda memperketatnya. Dan setiap penghalang memiliki biaya kecepatan—sebaiknya hitung dengan jujur sejak awal, karena baru menyadarinya seminggu kemudian akan lebih mahal.

Bagaimana Menetapkan Kriteria Penyelesaian yang Tidak Bisa Dipermainkan?#

Rumusan kriteria menentukan segala hal lainnya. Uji dengan satu pertanyaan: bisakah agen memenuhi kriteria ini tanpa melakukan apa pun?

• “Pastikan semuanya berfungsi”—bisa. Cukup tulis “sudah diperiksa, berfungsi.”
• “Jalankan build dan tunjukkan keluarannya”—sudah lebih sulit; agen harus mendapatkan keluarannya entah dari mana.
• “Jalankan aplikasinya, klik tombol checkout, lalu tunjukkan apa yang muncul di layar”—hampir tidak mungkin dipenuhi hanya dengan teks.

Perbedaan antara yang pertama dan yang ketiga adalah perbedaan antara laporan dan bukti.

Dokumentasi Claude Code menjelaskan empat tingkat ketelitian. Tangga yang berguna untuk dinaiki seiring meningkatnya biaya kesalahan:

1. Dalam satu pesan. Minta agen menjalankan pemeriksaan dan mengulanginya sampai berhasil di sini. Paling murah, cocok untuk hal-hal kecil.
2. Untuk seluruh sesi. Jadikan pemeriksaan sebagai syarat tujuan: evaluator terpisah memeriksanya setelah setiap giliran, dan agen terus bekerja sampai syarat terpenuhi. Detail teknisnya dibahas dalam panduan tentang menetapkan kriteria penyelesaian sejak awal.
3. Penghalang mekanis. Skrip berjalan ketika agen mencoba mengakhiri giliran dan mencegahnya selesai sampai pemeriksaan lolos. Ada satu detail penting: setelah delapan kali terhalang berturut-turut, Claude Code mengesampingkan penghalang itu dan tetap mengakhiri giliran. Tidak ada penghalang yang benar-benar tak tertembus dalam sistem ini.
4. Pendapat kedua. Peninjau terpisah dengan konteks baru yang bertugas membantah hasilnya.

Butir keempat berbeda karena merupakan satu-satunya yang tidak berkaitan dengan alat.

Siapa yang Seharusnya Menerima Pekerjaan Agen?#

Saat menjalankan agen dalam satu rangkaian untuk mengerjakan tugas besar, pengaturannya begini: satu kelompok menulis; kelompok baru lainnya menerima pekerjaan itu, tanpa ikut menulisnya.

“Baru” adalah kata kuncinya. Artinya konteks bersih yang tidak menyaksikan bagaimana setiap keputusan dibuat selama proses. Prompt berbeda dalam sesi yang sama tidak memberikan hal itu. Orang yang menulis kode sudah menghabiskan perhatian untuk meyakinkan diri sendiri bahwa kodenya benar, dan akan terus mencari pembenaran. Membantahnya bukan kepentingan mereka.

Rumusan tugas untuk peninjau lebih penting daripada model peninjau. Bandingkan:

• “Tinjau pekerjaan ini”—peninjau akan menemukan hal-hal yang mudah ditemukan lalu menulis “secara umum baik.”
• “Coba buktikan bahwa pekerjaan ini BELUM dilakukan”—peninjau akan mulai mencari celah karena itulah tujuannya.

Rumusan kedua bekerja lebih baik karena alasan yang sama dengan gagalnya ExploitGym: agen berkomitmen pada tujuan yang diberikan. Beri agen tujuan untuk menemukan celah, dan agen akan mencarinya.

Berikut rumusan lengkapnya, siap disalin apa adanya:

Anda sedang meninjau pekerjaan orang lain. Anda tidak menulisnya dan tidak perlu membelanya.

Tujuan Anda adalah membuktikan bahwa hasil yang diklaim BELUM tercapai. Temukan setidaknya tiga cara hasil itu mungkin belum tercapai meskipun semua pemeriksaan berstatus hijau.

Periksa dengan urutan berikut:

Pekerjaan apa yang berjalan di luar cakupan pemeriksaan—proses latar belakang, skrip terpisah, tugas terjadwal, penangan antrean.

Siapa yang memanggil setiap fungsi baru. Temukan pemanggilannya dengan menelusuri proyek; tunjukkan file dan barisnya.

Alur kebalikan: pengembalian dana, pemblokiran, pencabutan akses, kedaluwarsa, penghapusan sumber data.

Nilai-nilai di dalam hasil, bukan hanya apakah hasil itu ada.

Jika penelusuran yang jujur tidak menemukan celah, katakan demikian, tetapi sertakan dengan tepat apa yang Anda periksa dan bagaimana caranya.

Artikel tentang saat agen memeriksa dirinya sendiri dalam satu rangkaian menjelaskan cara kerja rangkaian ketika agen memeriksa dirinya di antara iterasi, serta di mana biasanya rangkaian itu gagal.

Apa yang Berubah Saat Anda Merumuskan Ulang Kriterianya?#

Inilah perbaikan termurah yang saya tahu, dan hampir tidak ada yang melakukannya.

Minta agen melakukan tinjauan kode—agen akan menalar dari sisi kode: struktur, penanganan kesalahan, percobaan ulang, area rentan. Berguna.

Minta agen menelusuri perjalanan pelanggan, dari kunjungan pertama ke situs hingga percobaan meminta pengembalian dana, dan jenis masalah yang berbeda akan muncul. Kesalahan yang menampilkan sesuatu yang tidak seharusnya dilihat pengguna. Surel yang teksnya tidak sesuai dengan apa yang sebenarnya terjadi. Langkah yang mustahil diselesaikan secara logis jika Anda tidak datang melalui skenario ideal.

Tinjauan kode tidak akan menemukan cacat-cacat ini, karena masing-masing sah dalam kode.

Dari situ saya berpegang pada satu aturan: jika pemeriksaan tidak menemukan apa pun, ubah rumusannya terlebih dahulu. Biasanya modelnya bukan masalahnya. Pekerjaan yang sama, ditanyakan dengan tiga cara berbeda, menghasilkan tiga daftar temuan yang berbeda. Seperangkat pertanyaan praktis untuk orang yang bukan programmer dikumpulkan secara terpisah: tujuh pemeriksaan kode tanpa kemampuan pemrograman.

Prompt Siap Pakai untuk Menerima Pekerjaan Agen#

Jangan jawab “selesai” atau “sudah diperiksa.” Saya perlu bukti.

Untuk setiap pekerjaan, berikan tepat hal-hal berikut:

Perintah apa yang Anda jalankan untuk memastikan pekerjaan itu berfungsi? Sertakan perintah itu sendiri dan seluruh keluarannya, tanpa dipersingkat.

Jika Anda tidak menjalankan perintahnya, katakan: “tidak dijalankan.” Jangan menggantinya dengan “sudah diperiksa secara visual” atau “logikanya benar.”

Pekerjaan apa yang berjalan di luar cakupan pemeriksaan Anda. Proses latar belakang, skrip terpisah, tugas terjadwal, penangan antrean—apa pun yang dimulai dengan cara berbeda dari aplikasi utama. Untuk setiap bagian seperti itu: apakah Anda menjalankannya secara terpisah, dan apa keluarannya?

Siapa yang memanggil setiap fungsi baru yang Anda tambahkan? Temukan pemanggilannya dengan menelusuri proyek dan tunjukkan file dan barisnya. Jika tidak ada pemanggilan, katakan langsung.

Lalu, di bagian terpisah: tiga cara hasil yang diklaim mungkin TIDAK tercapai meskipun semua pemeriksaan Anda berstatus hijau. Telusuri dengan sungguh-sungguh.

Di akhir, satu baris: apa yang harus saya periksa sendiri karena pemeriksaan otomatis tidak akan menangkapnya?

Butir keempat tampak sepele, tetapi menangkap seluruh jenis masalah. Dalam tugas besar yang saya bagi di antara agen berdasarkan area, satu-satunya “selesai” palsu dari seratus tugas ada tepat di sambungan dua area: kodenya sudah ditulis, pemeriksaannya hijau, dan tak seorang pun terpikir untuk menampilkannya di layar.

Empat Cara Mengelabui Diri Sendiri dengan Pemeriksaan#

1. Tidak menunggu semua peninjau. Saya meluncurkan tiga pemeriksaan paralel, dua kembali dengan hasil hijau, lalu saya melakukan deployment. Pemeriksaan ketiga tiba empat menit kemudian dengan enam pelanggaran. Memperbaiki sesuatu setelah dipublikasikan lebih mahal daripada menunggu dua menit.
2. Memercayai ringkasan “memproses N dari N.” Dalam penyebaran tugas yang besar, beberapa agen diam-diam gagal: mereka melaporkan keberhasilan, tetapi file-nya tidak tersentuh. Kini setelah setiap penulisan melalui agen, saya memverifikasi secara mekanis bahwa perubahan benar-benar ada di disk.
3. Tidak memeriksa dengan mata sendiri. Pemeriksaan otomatis bisa berstatus hijau untuk hasil yang sama sekali tidak dapat digunakan. Gambarnya secara teknis benar, ukurannya benar, kode responsnya benar. Namun sebenarnya, gambar itu adalah bingkai beku otomatis yang menggantikan sampul ilustrasi. Tidak ada pemeriksaan otomatis yang akan menangkapnya.
4. Memeriksa keberadaan alih-alih nilai. Pemeriksaan mencari teks wajib dalam hasil; teksnya ada, tetapi data di dalamnya salah: tanggalnya meleset satu hari. Pemeriksaan berstatus hijau, dan laporannya bohong. Kini saya memverifikasi seluruh nilai yang diharapkan, karena keberadaan kata yang benar saja tidak menjamin apa pun.

Keempatnya memiliki satu kesamaan: ada pemeriksaan, pemeriksaan itu tampak meyakinkan, tetapi yang diperiksa adalah hal yang salah. Mekanismenya sama dengan model dan tesnya, hanya tanpa daya cipta.

Mulai dari Mana Hari Ini#

Tiga langkah yang memerlukan dua puluh menit.

1. Ambil “selesai” yang terakhir. Periksa dengan prompt penerimaan di bagian tentang bukti. Tujuannya sederhana: lihat berapa banyak hal yang ditutup dengan kata-kata dan berapa banyak yang disertai keluaran perintah.
2. Buat satu aturan untuk diri sendiri. Kata “sudah diperiksa” tanpa keluaran perintah yang dilampirkan tidak dihitung sebagai penutupan. Aturan ini untuk Anda, bukan agen, dan itulah sebabnya aturan ini berhasil.
3. Pisahkan pekerja dan peninjau. Pada tugas berikutnya, berikan prompt peninjau kepada sesi baru dan minta sesi itu membuktikan bahwa pekerjaan BELUM dilakukan. Uji coba pertama biasanya sudah cukup untuk membenarkan kebiasaan ini.

Alat ini bagus dan makin baik setiap bulan: hal-hal yang setahun lalu bisa dilakukan agen secara diam-diam kini menghentikannya di jalurnya. Batas keamanan terus bergerak dan tetap menjadi sebuah batas. Selama agen mengejar tujuan yang diberikan kepadanya, pertanyaan “dan bagaimana persisnya Anda mengukurnya?” tetap menjadi tanggung jawab Anda. Kebiasaan memeriksa adalah jaring pengaman Anda.