Claude dan Codex semakin bodoh? Karena konteksmu terlalu berlebihan

作者：sysls

Diterjemahkan oleh: 深潮 TechFlow

Deep潮 Panduan Utama: Sysls, seorang blogger pengembang dengan 2,6 juta pengikut, menulis sebuah artikel panjang berisi pengalaman nyata yang telah dibagikan ulang oleh 827 orang dan mendapatkan 7000 like, dengan inti pesan: plugin, sistem memori, dan berbagai harness yang kamu gunakan kemungkinan besar malah menghambat. Artikel ini tidak berisi teori besar, melainkan prinsip-prinsip operasional yang langsung diambil dari proyek produksi nyata—mulai dari bagaimana mengendalikan konteks, menangani kecenderungan AI untuk menyenangkan, hingga bagaimana mendefinisikan kondisi akhir tugas. Ini adalah salah satu penjelasan paling jelas tentang praktik engineering Claude/Codex yang pernah saya lihat.

Selengkapnya sebagai berikut:

Pendahuluan

Kamu adalah seorang pengembang, setiap hari menggunakan CLI Claude dan Codex, setiap hari bertanya-tanya apakah kemampuan mereka sudah dimaksimalkan. Kadang-kadang kamu melihat mereka melakukan hal-hal yang sangat bodoh, dan tidak mengerti mengapa orang lain tampaknya membangun roket dengan AI, sementara kamu bahkan tidak bisa menumpuk dua batu dengan stabil.

Kamu mengira masalahnya ada pada harness-mu, plugin-mu, terminal-mu, atau apa pun. Kamu sudah pakai beads, opencode, zep, dan menulis 26.000 baris CLAUDE.md. Tapi apapun yang kamu lakukan, kamu tetap tidak mengerti mengapa semakin jauh dari surga, sementara orang lain bermain-main dengan para malaikat.

Itulah artikel yang selama ini kamu tunggu-tunggu.

Selain itu, saya tidak memiliki kepentingan pribadi. Saya katakan CLAUDE.md juga termasuk AGENT.md, dan Claude juga termasuk Codex—keduanya saya gunakan secara ekstensif.

Dalam beberapa bulan terakhir, saya mengamati satu hal menarik: hampir tidak ada orang yang benar-benar tahu bagaimana memaksimalkan kemampuan agen secara optimal.

Seperti ada segelintir orang yang mampu membangun seluruh dunia dengan agen, sementara yang lain berputar-putar di lautan alat, menderita sindrom pilihan—mengira bahwa menemukan paket, skill, atau harness yang tepat akan membuka jalan menuju AGI.

Hari ini, saya ingin mematahkan semua itu, dan meninggalkan satu kalimat sederhana dan jujur untuk kalian, lalu kita mulai dari sana. Kamu tidak perlu harness agen terbaru, tidak perlu menginstal sejuta paket, dan sama sekali tidak perlu membaca sejuta artikel demi tetap kompetitif. Faktanya, semangatmu bisa jadi malah merugikan.

Saya bukan untuk jalan-jalan—saya mulai pakai ini saat agen sudah bisa menulis kode. Saya sudah coba semua paket, semua harness, semua paradigma. Saya pernah buat pabrik agen untuk menulis sinyal, infrastruktur, dan pipeline data—bukan proyek main-main, melainkan kasus nyata yang berjalan di lingkungan produksi. Setelah semua itu…

Hari ini, saya menggunakan konfigurasi yang sangat sederhana, hampir sesederhana mungkin, hanya dengan CLI dasar (Claude Code dan Codex), ditambah pemahaman tentang beberapa prinsip dasar engineering agen, dan hasilnya adalah pekerjaan paling inovatif yang pernah saya capai.

Memahami bahwa dunia sedang bergerak sangat cepat

Pertama-tama, saya ingin mengatakan bahwa perusahaan model dasar sedang dalam sebuah lompatan besar yang revolusioner, dan jelas tidak akan berhenti dalam waktu dekat. Setiap peningkatan dalam “kecerdasan agen” akan mengubah cara kamu berinteraksi dengannya, karena agen dirancang semakin patuh terhadap instruksi.

Hanya beberapa generasi yang lalu, jika kamu menulis di CLAUDE.md “sebelum melakukan apa pun, baca READTHISBEFOREDOINGANYTHING.md”, kemungkinan 50% dia akan bilang “mampus lu”, lalu melakukan apa yang dia mau. Sekarang, dia mengikuti sebagian besar instruksi, bahkan instruksi bersarang yang kompleks—misalnya kamu bisa bilang “baca A dulu, lalu baca B, kalau C, baca D”, dan dia biasanya akan mengikuti.

Apa artinya ini? Prinsip terpenting adalah menyadari bahwa setiap generasi baru agen memaksa kamu untuk memikirkan ulang apa solusi terbaik, dan inilah mengapa less is more.

Ketika kamu menggunakan banyak library dan harness, kamu mengunci diri dalam satu “solusi”, tetapi masalah ini mungkin tidak ada lagi di generasi agen berikutnya. Kamu tahu siapa pengguna paling antusias dan paling banyak memakai agen? Benar—karyawan perusahaan terdepan, yang punya anggaran token tak terbatas dan memakai model terbaru.

Apa artinya ini? Jika sebuah masalah nyata ada dan ada solusi yang bagus, perusahaan terdepan akan menjadi pengguna terbesar dari solusi itu. Lalu apa yang mereka lakukan selanjutnya? Mereka akan mengintegrasikan solusi itu ke dalam produk mereka. Pikirkan, mengapa sebuah perusahaan mengizinkan produk lain menyelesaikan masalah nyata dan menciptakan ketergantungan eksternal? Bagaimana saya tahu ini nyata? Lihat skill, harness memori, sub-agen… semuanya dimulai dari solusi nyata yang telah teruji dan terbukti berguna.

Jadi, jika sesuatu benar-benar inovatif dan bisa memperluas penggunaan agen secara bermakna, pasti akan diintegrasikan ke produk inti perusahaan dasar. Percayalah, perusahaan dasar sedang bergerak sangat cepat. Jadi santai saja, kamu tidak perlu menginstal apa pun atau bergantung pada eksternal untuk menghasilkan pekerjaan terbaik.

Saya prediksi, kolom komentar akan segera penuh dengan “SysLS, saya pakai harness tertentu, luar biasa! Saya bangun Google dalam satu hari!”—saya ucapkan: selamat! Tapi kamu bukan target utama, kamu mewakili komunitas yang sangat kecil dan benar-benar paham engineering agen.

Konteks adalah segalanya

Serius. Konteks adalah segalanya. Masalah lain dari menggunakan ribuan plugin dan dependensi eksternal adalah kamu rentan terhadap “inflasi konteks”—artinya, agenmu terlalu banyak informasi yang membuatnya bingung.

Bayangkan kamu mau buat game tebak kata pakai Python? Mudah. Tapi, apa catatan “manage memory” di 26 percakapan lalu? Ah, pengguna terjebak di layar karena kita terlalu banyak membuat subprocess. Haruskah selalu menulis catatan? Baiklah… apa hubungannya dengan game tebak kata?

Kamu tahu. Kamu hanya ingin memberi agen informasi yang tepat dan cukup untuk menyelesaikan tugas. Semakin baik kamu mengendalikan ini, semakin baik performa agen. Tapi begitu kamu mulai memperkenalkan sistem memori aneh, plugin, atau skill yang terlalu banyak dan membingungkan, kamu sebenarnya memberi instruksi untuk membuat bom dan resep kue sekaligus—padahal kamu cuma ingin dia menulis puisi tentang hutan redwood.

Jadi, saya kembali mengingatkan—hilangkan semua dependensi, lalu…

Lakukan hal yang benar-benar berguna

Deskripsikan detail implementasi secara tepat

Ingat, ingat bahwa konteks adalah segalanya?

Ingat bahwa kamu ingin memberi agen informasi yang tepat dan cukup untuk menyelesaikan tugas?

Cara pertama untuk melakukan ini adalah memisahkan riset dan implementasi. Kamu harus sangat tepat dalam mendeskripsikan apa yang kamu minta agen lakukan.

Apa akibat dari tidak tepat? “Buatkan sistem otentikasi.” Agen harus riset: apa itu sistem otentikasi? Pilihan apa saja? Kelebihan dan kekurangannya? Sekarang dia harus cari di internet info yang sebenarnya tidak berguna, dan di konteksnya penuh dengan detail implementasi yang mungkin tidak relevan. Saat saatnya implementasi, dia bisa bingung, atau malah berimajinasi tentang solusi yang tidak perlu.

Sebaliknya, jika kamu bilang “gunakan bcrypt-12 hash password untuk JWT, rotasi token, kedaluwarsa 7 hari…”, dia tidak perlu riset apa pun, tahu apa yang kamu inginkan, dan bisa mengisi konteks dengan detail implementasi.

Tentu saja, kamu tidak selalu tahu detail implementasi. Banyak kali kamu tidak tahu apa yang benar, bahkan ingin menyerahkan keputusan detail ke agen. Bagaimana kalau begitu? Mudah—buat tugas riset untuk eksplorasi berbagai kemungkinan, biarkan agen memutuskan sendiri atau biarkan agen lain yang punya konteks baru untuk mengimplementasikan.

Begitu kamu mulai berpikir seperti ini, kamu akan menyadari bagian-bagian workflow di mana konteks agen terkontaminasi secara tidak perlu, dan kamu bisa membangun “pagar” di workflow agen, mengabstraksi informasi yang tidak perlu, dan menyisakan konteks tertentu yang membuat agen tampil optimal dalam tugasnya. Ingat, kamu punya anggota tim yang sangat berbakat dan cerdas, tahu semua jenis bola di alam semesta—tapi kecuali kamu beri tahu dia bahwa kamu ingin mendesain ruang yang menyenangkan dan bisa menari, dia akan terus membicarakan manfaat bola-bola.

Keterbatasan desain yang terlalu mengakomodasi kecenderungan menyenangkan

Tidak ada yang mau pakai produk yang terus-menerus mengkritik, menyalahkan, atau mengabaikan instruksi kamu. Jadi, agen akan berusaha menyetujui dan melakukan apa yang kamu inginkan.

Kalau kamu buat dia menambahkan “happy” setiap tiga kata, dia akan berusaha keras mengikuti—ini dipahami banyak orang. Kepatuhan ini yang membuatnya sangat berguna. Tapi, ada satu fitur menarik: ini berarti kalau kamu bilang “carikan bug di kode”, dia akan menemukan bug—bahkan mungkin “menciptakan” satu. Kenapa? Karena dia sangat ingin mengikuti perintahmu!

Banyak orang cepat mengeluh tentang LLM yang sering berimajinasi dan memalsukan hal yang tidak ada, tapi mereka tidak sadar bahwa masalahnya ada di diri mereka sendiri. Kamu minta apa, dia berikan apa—bahkan kalau harus sedikit memanipulasi fakta!

Lalu, apa solusinya? Saya temukan “prompt netral” sangat efektif, yaitu tidak memihak ke hasil tertentu. Misalnya, saya tidak bilang “carikan bug di database”, tapi “scan seluruh database, ikuti logika setiap komponen, laporkan semua temuan.”

Prompt netral ini kadang menemukan bug, kadang hanya mendeskripsikan bagaimana kode berjalan secara objektif. Tapi dia tidak memihak ke asumsi “ada bug”.

Cara lain mengatasi kecenderungan menyenangkan adalah mengubahnya menjadi keunggulan. Saya tahu agen berusaha menyenangkan dan mengikuti instruksi, jadi saya bisa memihak ke satu sisi atau lainnya.

Misalnya, saya minta agen pencari bug untuk menilai semua bug di database, beri skor +1 untuk bug kecil, +5 untuk bug sedang, +10 untuk bug besar. Saya tahu agen ini akan sangat antusias mengidentifikasi semua bug (termasuk yang sebenarnya bukan bug), dan melaporkan skor total misalnya 104. Saya anggap ini sebagai super-set dari semua kemungkinan bug.

Lalu, saya buat agen lain yang bertugas membantah, dan bilang bahwa setiap kali berhasil membantah bug, dia mendapatkan poin sesuai bug tersebut, tapi kalau salah, poinnya dikurangi dua kali lipat. Agen ini akan berusaha membantah sebanyak mungkin, tapi karena ada penalti, dia akan berhati-hati. Dia tetap akan aktif membantah bug (termasuk bug nyata). Saya anggap ini sebagai subset dari semua bug nyata.

Akhirnya, saya buat agen penilai yang menggabungkan input keduanya dan memberi skor. Saya beri tahu bahwa saya punya jawaban benar, dan jika dia benar, dapat +1, salah -1. Jadi, dia menilai masing-masing “bug” dari agen pencari dan pembantah. Yang dianggap benar adalah yang sesuai kenyataan, dan saya verifikasi. Dalam banyak kasus, metode ini sangat akurat, jarang salah, dan mendekati operasi tanpa cacat.

Mungkin kamu merasa agen pencari bug saja sudah cukup, tapi metode ini sangat efektif karena memanfaatkan sifat bawaan agen—ingin menyenangkan.

Bagaimana menilai apa yang berguna dan apa yang layak dipakai?

Pertanyaan ini tampak rumit, seolah harus belajar mendalam dan selalu mengikuti perkembangan AI, tapi sebenarnya sangat sederhana… Jika OpenAI dan Claude mengimplementasikan atau mengakuisisi perusahaan yang mengembangkan fitur tersebut, besar kemungkinan fitur itu berguna.

Perhatikan bahwa “skill” sudah ada di mana-mana dan menjadi bagian dari dokumentasi resmi Claude dan Codex? Perhatikan bahwa OpenAI mengakuisisi OpenClaw? Perhatikan bahwa Claude segera menambahkan fitur memori, suara, dan remote work?

Bagaimana dengan planning? Masih ingat banyak orang yang menemukan bahwa perencanaan sebelum eksekusi sangat berguna, dan ini menjadi fitur inti?

Ya, itu semua sangat berguna!

Ingat juga fitur stop-hooks yang tak berujung, sangat berguna karena agen sangat enggan melakukan pekerjaan jangka panjang… lalu saat Codex 5.2 keluar, kebutuhan itu hilang dalam semalam?

Itulah semua yang perlu kamu tahu… jika sesuatu benar-benar penting dan berguna, Claude dan Codex akan mengimplementasikannya sendiri! Jadi, kamu tidak perlu khawatir harus pakai “fitur baru” atau “mengenal yang baru”, bahkan tidak perlu “selalu update”.

Bantu saya sebentar. Sesekali, perbarui alat CLI pilihanmu, baca apa saja fitur baru yang ditambahkan. Itu sudah cukup.

Kompresi, konteks, dan asumsi

Beberapa orang mengalami jebakan besar saat menggunakan agen: kadang mereka tampak sangat cerdas, dan kadang kamu tidak percaya mereka bisa menipu.

“Ini cerdas? Ini bodoh banget!”

Perbedaan terbesar adalah apakah agen dipaksa membuat asumsi atau “mengisi kekosongan”. Saat ini, mereka masih buruk dalam “menghubungkan titik” dan “mengisi kekosongan” atau membuat asumsi. Begitu mereka melakukannya, langsung terlihat, dan situasinya memburuk.

Salah satu aturan terpenting di CLAUDE.md adalah tentang bagaimana mendapatkan konteks, dan menginstruksikan agen untuk membaca aturan itu sebagai hal pertama setiap kali membaca CLAUDE.md (setelah kompresi). Sebagai bagian dari aturan pengambilan konteks, beberapa instruksi sederhana bisa sangat berpengaruh: baca ulang rencana tugas, dan sebelum melanjutkan, baca ulang dokumen terkait.

Beritahu agen bagaimana mengakhiri tugas

Kita manusia punya rasa yang cukup jelas tentang kapan sebuah tugas selesai. Tapi untuk agen, masalah terbesar saat ini adalah mereka tahu bagaimana memulai tugas, tapi tidak tahu bagaimana mengakhirinya.

Ini sering menyebabkan hasil yang sangat frustrasi: agen akhirnya hanya membuat stub dan selesai.

Pengujian adalah tonggak yang sangat baik karena bersifat deterministik, kamu bisa menetapkan ekspektasi yang sangat jelas. Jika tidak semua pengujian ini lolos, tugas belum selesai; dan kamu tidak boleh mengubah pengujian.

Lalu, cukup review pengujian, dan begitu semua lolos, kamu bisa tenang. Kamu juga bisa otomatisasi ini, tapi intinya—ingat bahwa “mengakhiri tugas” adalah hal yang sangat alami bagi manusia, tapi tidak bagi agen.

Tahukah kamu, baru-baru ini ada cara lain yang cukup efektif sebagai titik akhir tugas? Screenshot + verifikasi. Kamu bisa minta agen menyelesaikan sesuatu sampai semua pengujian lolos, lalu minta dia screenshot dan verifikasi bahwa “desain atau perilaku” di screenshot sesuai harapan.

Ini memungkinkan kamu melakukan iterasi dan mengarahkan agen ke desain yang diinginkan, tanpa khawatir dia berhenti setelah percobaan pertama!

Ekstensi alami dari ini adalah membuat “kontrak” dengan agen, dan menanamkannya ke dalam aturan. Misalnya, {TASK}CONTRACT.md yang menentukan apa yang harus dilakukan sebelum kamu diizinkan mengakhiri sesi. Di {TASK}CONTRACT.md, kamu akan menentukan pengujian, screenshot, dan verifikasi lain yang harus diselesaikan sebelum tugas dianggap selesai.

Agen yang selalu berjalan

Sering saya ditanya, bagaimana cara membuat agen berjalan 24 jam penuh dan tetap aman dari penyimpangan?

Ada cara yang sangat sederhana. Buat stop-hook yang mencegah agen mengakhiri sesi, kecuali semua bagian {TASK}_CONTRACT.md selesai.

Kalau kamu punya 100 kontrak yang sangat spesifik dan berisi apa yang ingin kamu bangun, stop-hook akan mencegah agen berhenti sampai semua kontrak selesai, termasuk semua pengujian dan verifikasi!

Saran profesional: saya temukan bahwa sesi berjalan 24 jam tidak selalu optimal. Sebagian karena struktur ini secara inheren memperkenalkan inflasi konteks, karena semua kontrak yang tidak relevan masuk ke satu sesi yang sama!

Jadi, saya tidak merekomendasikan ini.

Alternatif yang lebih baik adalah menjalankan setiap kontrak dalam sesi baru. Setiap kali kamu perlu melakukan sesuatu, buat kontrak baru.

Buat lapisan orkestrasi yang akan membuat kontrak baru dan sesi baru saat diperlukan.

Ini akan mengubah pengalaman agenmu secara drastis.

Iterasi, iterasi, iterasi

Kamu menyewa asisten administratif, kamu berharap dia tahu jadwalmu dari hari pertama? Atau bagaimana kamu minum kopi? Kamu makan malam jam 6 malam bukan jam 8? Tentu tidak. Kamu akan membangun preferensi seiring waktu.

Begitu juga agen. Mulai dari konfigurasi paling sederhana, lupakan struktur kompleks dan harness, berikan CLI dasar kesempatan.

Lalu, secara bertahap, tambahkan preferensimu. Bagaimana caranya?

Aturan

Kalau kamu tidak ingin agen melakukan sesuatu, tulis aturan. Lalu, di CLAUDE.md, beri tahu agen aturan itu. Misalnya: “Sebelum menulis kode, baca coding-rules.md.” Aturan bisa bersarang, bisa bersyarat! Kalau kamu sedang menulis kode, baca coding-rules.md; kalau sedang menulis tes, baca coding-test-rules.md. Kalau tes gagal, baca coding-test-failing-rules.md. Kamu bisa buat aturan dengan cabang logika apa pun, dan Claude (dan Codex) akan senang mengikuti, asalkan di CLAUDE.md ada penjelasan yang jelas.

Sebenarnya, ini adalah saran praktis pertama yang saya berikan: anggap CLAUDE.md sebagai sebuah direktori logis dan bersarang, yang menjelaskan di mana mencari konteks dalam skenario dan hasil tertentu. Buat sesederhana mungkin, hanya berisi IF-ELSE tentang “dalam kondisi apa harus mencari di mana.”

Kalau kamu melihat agen melakukan sesuatu yang tidak kamu setujui, tambahkan sebagai aturan, dan beri tahu agen untuk membacanya sebelum melakukan hal itu lagi. Pasti dia tidak akan mengulanginya.

Skill

Skill mirip aturan, tapi lebih cocok untuk mendeskripsikan “langkah-langkah operasional” daripada preferensi kode. Kalau kamu ingin sesuatu dilakukan dengan cara tertentu, masukkan ke skill.

Banyak orang mengeluh mereka tidak tahu bagaimana agen menyelesaikan masalah, dan ini membuat mereka tidak nyaman. Kalau kamu ingin kepastian, buat agen riset dulu bagaimana dia akan menyelesaikan masalah itu, lalu tulis solusi itu sebagai file skill. Kamu bisa melihat sebelumnya bagaimana agen akan menangani masalah itu, dan memperbaikinya sebelum benar-benar dihadapi.

Bagaimana cara memberi tahu agen tentang skill ini? Mudah! Di CLAUDE.md, tulis bahwa saat kamu menghadapi skenario ini dan perlu melakukan ini, baca SKILL.md.

Mengelola aturan dan skill

Kamu pasti ingin terus menambah aturan dan skill. Ini adalah cara kamu memberi agen kepribadian dan memori preferensi. Hampir semua hal lain tidak terlalu penting.

Begitu kamu mulai melakukan ini, agenmu akan terasa seperti sihir. Dia akan “melakukan sesuai keinginanmu.” Dan akhirnya, kamu akan merasa “mengerti” tentang engineering agen.

Lalu…

Kinerja mulai menurun lagi.

Kenapa?

Sederhana. Semakin banyak aturan dan skill yang kamu tambahkan, mereka mulai saling bertentangan, atau agen mengalami inflasi konteks yang parah. Kalau kamu harus membaca 14 file markdown sebelum mulai coding, masalah yang sama akan muncul: informasi tidak relevan memenuhi konteks.

Apa solusinya?

Bersihkan. Buat agenmu “spa”, integrasikan aturan dan skill, dan gunakan preferensi yang kamu perbarui untuk menghilangkan konflik.

Lalu, semuanya kembali terasa seperti sihir.

Itulah rahasianya. Tetap sederhana, gunakan aturan dan skill, anggap CLAUDE.md sebagai direktori, dan perhatikan konteks serta batasan desainnya.

Bertanggung jawab atas hasil

Tidak ada agen yang sempurna hari ini. Kamu bisa menyerahkan banyak desain dan implementasi ke agen, tapi kamu harus bertanggung jawab atas hasilnya.

Jadi, berhati-hatilah… dan nikmati!

Mainkan mainan masa depan (dan jelas, gunakan itu untuk hal serius) adalah kesenangan tersendiri!