Claude dan Codex semakin bodoh? Karena konteksmu terlalu berlebihan

Dari bagaimana mengendalikan konteks, menangani kecenderungan AI untuk menyenangkan, hingga bagaimana mendefinisikan kondisi akhir tugas, ini adalah salah satu artikel paling jelas yang pernah saya lihat tentang praktik rekayasa Claude/Codex.

Penulis: sysls

Diterjemahkan: Deep潮 TechFlow

Deep潮 Pengantar: Seorang blogger pengembang dengan 2,6 juta pengikut, sysls, menulis sebuah artikel panjang praktis yang dibagikan ulang oleh 827 orang dan disukai oleh 7000 orang, dengan inti hanya satu kalimat: plugin, sistem memori, dan berbagai harness yang kamu gunakan kemungkinan besar malah membantu memperburuk keadaan. Artikel ini tidak membahas teori besar, melainkan berisi prinsip-prinsip operasional yang langsung diambil dari proyek nyata—dari cara mengendalikan konteks, menangani kecenderungan AI untuk menyenangkan, hingga bagaimana mendefinisikan kondisi akhir tugas—yang paling jelas saya temui dalam praktik rekayasa Claude/Codex.

Berikut teks lengkapnya:

Pendahuluan

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

Kamu merasa ini masalah harness-mu, plugin-mu, terminal-mu, atau apa pun. Kamu sudah pakai beads, opencode, zep, dan CLAUDE.md-mu sudah 26.000 baris. Tapi entah bagaimana, kamu tetap tidak mengerti mengapa semakin jauh dari surga, sementara orang lain bermain-main dengan para malaikat.

Ini adalah artikel yang selama ini kamu tunggu-tunggu.

Selain itu, saya tidak punya kepentingan pribadi. Saya katakan CLAUDE.md juga termasuk AGENT.md, saya katakan Claude juga termasuk Codex, karena saya pakai keduanya secara besar-besaran.

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

Rasanya seperti hanya segelintir orang yang mampu membangun seluruh dunia dengan agen, sementara yang lain tersesat di lautan alat, menderita sindrom pilihan—mengira bahwa menemukan paket, skill, atau kombinasi 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 memasang 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 hampir 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, tapi kasus nyata yang berjalan di lingkungan produksi. Setelah semua ini…

Hari ini, saya menggunakan konfigurasi yang hampir sesederhana mungkin, hanya dengan CLI dasar (Claude Code dan Codex), ditambah pemahaman tentang beberapa prinsip dasar rekayasa agen, dan saya berhasil membuat pekerjaan paling inovatif yang pernah saya lakukan.

Memahami Dunia yang Sedang Melaju Pesat

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

Hanya beberapa generasi lalu, jika kamu menulis di CLAUDE.md “sebelum melakukan apa pun, baca READTHISBEFOREDOINGANYTHING.md”, kemungkinan 50% dia akan membalas “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 berbeda, 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 sendiri. Pikirkan, mengapa sebuah perusahaan membiarkan produk lain menyelesaikan masalah nyata dan menciptakan ketergantungan eksternal? Bagaimana saya tahu ini nyata? Lihat skill, memori harness, sub-agen… semuanya berasal dari solusi nyata yang telah terbukti berguna melalui pengalaman nyata.

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

Saya prediksi di kolom komentar nanti akan muncul “SysLS, saya pakai harness tertentu, luar biasa! Saya bisa bangun ulang Google dalam sehari!”—saya ucapkan: selamat! Tapi kamu bukan target utama, kamu mewakili komunitas kecil yang benar-benar memahami rekayasa agen.

Konteks adalah Segalanya

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

Mau saya buatkan game tebak kata pakai Python? Mudah. Tunggu, apa catatan “kelola memori” sebelum 26 percakapan ini? Ah, pengguna terjebak di layar karena kita terlalu banyak membuat subprocess. Selalu harus catat? Baiklah… apa hubungannya ini dengan game tebak kata?

Kamu tahu. Kamu hanya ingin memberi agen informasi yang tepat untuk menyelesaikan tugas, tidak lebih dan tidak kurang! Semakin baik pengendalianmu terhadap ini, semakin baik performa agen. Begitu kamu mulai memperkenalkan sistem memori aneh, plugin, atau terlalu banyak skill yang namanya membingungkan, kamu sebenarnya memberi instruksi untuk membuat bom dan resep kue sekaligus, padahal kamu hanya ingin dia menulis puisi kecil tentang hutan redwood.

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

Lakukan yang benar-benar berguna

Deskripsikan detail implementasi secara tepat

Ingat kan, bahwa konteks adalah segalanya?

Ingat bahwa kamu ingin memberi agen informasi yang tepat, tidak lebih dan tidak kurang?

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

Apa akibat dari tidak tepat? “Buatkan sistem otentikasi.” Agen harus mencari tahu: apa itu sistem otentikasi? Pilihan apa saja? Kelebihan dan kekurangannya? Sekarang dia harus cari di internet banyak informasi yang sebenarnya tidak berguna, dan isi konteks dengan berbagai kemungkinan detail implementasi. Saat saatnya implementasi, dia akan lebih mudah bingung, atau malah mengimajinasikan hal-hal yang tidak relevan dan tidak perlu.

Sebaliknya, jika kamu bilang “gunakan bcrypt-12 hash password untuk JWT, rotasi refresh token, kedaluwarsa 7 hari…”, dia tidak perlu riset alternatif lain, 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—buatkan tugas riset untuk eksplorasi berbagai kemungkinan implementasi, biarkan dia memutuskan sendiri, atau biarkan agen lain dengan konteks baru yang melakukan implementasi.

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 agenmu, mengabstraksi informasi yang tidak perlu dari agen, dan menyisakan konteks tertentu yang membuatnya tampil optimal dalam tugas.

Ingat, kamu punya anggota tim yang sangat berbakat dan cerdas, tahu semua jenis bola di alam semesta—tapi kecuali kamu bilang dia ingin mendesain ruang untuk menari dan bersenang-senang, dia akan terus membicarakan manfaat bola-bola.

Keterbatasan desain yang menyenangkan

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

Kalau kamu suruh dia tiap 3 kata tambahkan “senang”, dia akan berusaha keras mengikuti—ini dipahami banyak orang. Kepatuhannya inilah yang membuatnya sangat berguna. Tapi ada satu fitur menarik: ini berarti kalau kamu bilang “bantu saya cari bug di kode”, dia akan menemukan bug—bahkan mungkin “menciptakan” satu. Kenapa? Karena dia sangat ingin mengikuti instruksi kamu!

Banyak orang cepat mengeluh tentang LLM yang sering berhalusinasi dan mengarang hal yang tidak ada, tapi mereka tidak sadar bahwa masalahnya ada di diri mereka sendiri. Kamu suruh dia cari apa, dia akan 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 “bantu saya cari bug di database”, tapi bilang “scan seluruh database, ikuti logika setiap komponen, laporkan semua yang ditemukan.”

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 kekuatan. Saya tahu agen berusaha menyenangkan dan mengikuti instruksi saya, jadi saya bisa memiringkannya ke satu arah atau lainnya.

Misalnya, saya minta agen pencari bug mengidentifikasi semua bug di database, beri skor +1 untuk bug kecil, +5 untuk yang sedang, +10 untuk yang serius. Saya tahu agen ini akan sangat antusias mengidentifikasi semua jenis 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 lawan yang berusaha membantah, katakan bahwa setiap bug yang berhasil dibantah mendapatkan poin sesuai skornya, tapi kalau salah membantah, poinnya dikurangi dua kali lipat. Agen ini akan berusaha membantah sebanyak mungkin bug, 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 juri yang menggabungkan input keduanya dan memberi skor. Saya beri tahu bahwa saya punya jawaban benar, dan dia mendapatkan +1 poin kalau benar, -1 kalau salah. Jadi dia menilai setiap bug dari agen pencari bug dan agen lawan. Jika juri mengatakan apa yang benar, saya verifikasi. Dalam banyak kasus, metode ini sangat akurat, meskipun kadang salah, tapi sudah mendekati operasi tanpa kesalahan.

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

Bagaimana menilai apa yang berguna dan apa yang layak dipakai?

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

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

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

Ya, itu sangat berguna!

Ingat juga hook stop yang tak berujung sangat berguna karena agen sangat enggan melakukan pekerjaan jangka panjang… lalu, begitu 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 memakai “fitur baru” atau “mengenal yang baru”, bahkan tidak perlu “selalu update”.

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

Kompresi, Konteks, dan Asumsi

Beberapa orang mengalami jebakan besar saat memakai 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 sangat buruk dalam “menghubungkan titik” atau “mengisi kekosongan” dan membuat asumsi. Begitu mereka melakukannya, hasilnya langsung terlihat buruk.

Salah satu aturan terpenting di CLAUDE.md adalah tentang bagaimana mendapatkan konteks, dan mengarahkan agen agar membaca aturan ini setiap kali membaca CLAUDE.md (setelah setiap kompresi). Sebagai bagian dari aturan mendapatkan konteks, beberapa instruksi sederhana bisa sangat membantu: baca ulang rencana tugas, dan sebelum melanjutkan, baca ulang dokumen terkait.

Beritahu agen bagaimana mengakhiri tugas

Perasaan manusia tentang “selesai” cukup jelas. 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 pasti, kamu bisa menetapkan ekspektasi yang sangat jelas. Kalau tidak melewati X pengujian, tugas belum selesai; dan kamu tidak mengubah pengujian.

Lalu, kamu 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.

Apa yang baru-baru ini menjadi titik akhir tugas yang layak? Screenshot + verifikasi. Kamu bisa minta agen menyelesaikan sesuatu sampai semua pengujian lolos, lalu ambil screenshot dan verifikasi bahwa desain atau perilaku di screenshot sesuai harapan.

Ini memungkinkan kamu mengulangi dan mengarahkan agen ke desain yang kamu inginkan, tanpa khawatir dia berhenti setelah percobaan pertama!

Ekstensi alami dari ini adalah membuat “kontrak” dengan agen, dan menyisipkannya ke dalam aturan. Misalnya, {TASK}CONTRACT.md 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 mengonfirmasi bahwa tugas selesai.

Agen yang selalu berjalan

Saya sering ditanya, bagaimana orang bisa menjalankan agen 24 jam penuh dan memastikan tidak menyimpang?

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 jelas dan berisi apa yang ingin kamu bangun, stop-hook ini akan mencegah agen berhenti sampai semua 100 kontrak selesai, termasuk semua pengujian dan verifikasi yang diperlukan!

Saran profesional: Saya temukan bahwa sesi berjalan 24 jam tidak selalu optimal. Sebab, dari struktur, ini akan memaksa inflasi konteks karena semua kontrak yang tidak relevan masuk ke satu sesi!

Jadi, saya tidak merekomendasikan ini.

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

Buat lapisan orkestrasi yang membuat kontrak baru saat “sesuatu harus dilakukan”, dan buat sesi baru untuk menangani kontrak itu.

Ini akan mengubah pengalaman agenmu secara drastis.

Iterasi, iterasi, iterasi

Kamu mempekerjakan asisten administratif, kamu berharap dia tahu jadwalmu dari hari pertama? Atau bagaimana kamu minum kopi? Kamu makan malam jam 6 malam bukan jam 8? Jelas 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, tambahkan preferensimu secara bertahap. Bagaimana caranya?

Aturan

Kalau kamu tidak ingin agen melakukan sesuatu, buat aturan. Lalu, di CLAUDE.md, beritahu agen tentang aturan ini. 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 logika cabang 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 direktori logis dan bersarang, yang menunjukkan di mana mencari konteks dalam skenario dan hasil tertentu. Harus sesederhana mungkin, hanya berisi IF-ELSE tentang “dalam kondisi apa cari di mana.”

Kalau kamu lihat agen melakukan sesuatu yang tidak kamu setujui, tambahkan sebagai aturan, beritahu agen untuk membacanya sebelum melakukan lagi, dan dia pasti tidak akan mengulanginya.

Skill

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

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

Bagaimana cara memberitahu agen bahwa skill ini ada? Betul! 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 preferensi yang melekat padanya. Hampir semua hal lain tidak penting.

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

Lalu…

Kinerja mulai menurun lagi.

Apa yang terjadi?!

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

Apa solusinya?

Bersihkan. Buat agenmu “spa”, integrasikan aturan dan skill, dan perbarui preferensimu agar tidak bertentangan.

Lalu, semuanya akan terasa seperti sihir lagi.

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

Bertanggung jawab atas hasil

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

Jadi, berhati-hatilah… dan nikmati prosesnya!

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